Основы проектирования реляционных баз данных
Иерархическая модель
Иерархическая модель данных организует данные в виде древовидной структуры и является реализацией логических связей между данными типа родовидовых отношений или отношений "часть-целое". Примером простого иерархического представления может служить административная структура организации.Деревом в информатике называют совокупность корневого элемента и множества подчиненных ему элементов, в которой отношения между элементами носят подчиненный вертикальный характер. Горизонтальные связи в такой системе отношений не допускаются.
Элементы описания данных в этой модели такие же, как и в сетевой: простое поле, группа, запись, групповое отношение и БД. Существенное ее отличие от сетевой модели данных касается средств организации связей, а именно, допускаются связи между объектами модели в виде древовидной структуры.
Особенностью такого представления данных является наличие нескольких подчиненных уровней. В иерархической модели имеется корневой узел или корень дерева. Он располагается на 1-м, самом высоком уровне и не имеет узлов-предшественников. Остальные узлы называются порожденными и связаны между собой следующим образом: каждый узел имеет исходный, находящийся на вышестоящем уровне. На следующем уровне каждый узел может иметь более одного узла-потомка или не иметь потомков вовсе. Узлы, не имеющие порожденных, называются листьями. В иерархии рассматривают уровни, на которых расположен тот или иной узел или совокупность узлов.
Между исходным узлом и порожденными узлами по условию модели существует связь "один-ко-многим" (или "многие-к-одному").
Иерархия должна удовлетворять следующим условиям:
При этом каждый экземпляр исходного узла начинает логическую запись.
К основным недостаткам иерархической модели можно отнести:
Пример. Пусть требуется построить иерархическую модель о преподавателях, студентах и дисциплинах, которые преподаватели преподают, а студенты изучают.
Предположим, что каждый преподаватель может читать несколько дисциплин, а каждый студент также может изучать несколько дисциплин.
Один из возможных вариантов построения иерархической модели может быть таковым. Корневым узлом является студент (Номер студента, ФИО, Номер группы). Для каждого студента при данном представлении имеется экземпляр корневого узла. Преподаватель и дисциплина объединяются в один порожденный узел (Табельный номер преподавателя, ФИО, Ученое звание, Кафедра, Дисциплина, Дата экзамена, Оценка, Зачет).
При такой организации данных достаточно легко получать ответы на запросы типа "выдать информацию о сдаче экзаменов студентами по различным дисциплинам". Однако при ответе на вопрос, какие преподаватели принимают экзамены по ВТ, необходимо просмотреть все записи порожденных узлов для каждого корневого узла. Для этого вопроса более подходит модель, в которой корневым узлом является преподаватель (Табельный номер преподавателя, ФИО, ученое звание, кафедра), а порожденным является студент (номер студента, ФИО, номер группы, дисциплина, дата сдачи, оценка, зачет).
В первом варианте модели для каждого студента дублируется информация (в экземпляре порожденного узла) о преподавателях и дисциплине, а во втором - для каждого преподавателя о студентах. Отсюда возникают проблемы включения и удаления данных. Из принципа иерархии следует, что экземпляр порожденного узла не может существовать в отсутствие соответствующего ему экземпляра исходного узла.
Таким образом, невозможно без привлечения дополнительных способов включить в базу данных информацию о преподавателях, которые не принимают экзамены (для первого варианта схемы). Чтобы соблюсти принцип иерархии, нужно сформировать, например, пустой исходный узел и породить еще проблему интерпретации нуль-значений.
При удалении исходного узла автоматически удаляются экземпляры порожденных узлов. Так, для второго варианта представления модели удаления сведения о преподавателе (уволился) удаляются все сведения о студентах, у него обучавшихся, а следовательно, теряется информация, необходимая для оценки качества обучения студентов.
Первопричиной этих проблем является то обстоятельство, что иерархическая модель не поддерживает отношение M:N.
Основной единицей обработки здесь является запись, к которой применимы операции ЗАПОМНИТЬ, МОДИФИЦИРОВАТЬ, УДАЛИТЬ, ИЗВЛЕЧЬ, НАЙТИ. В операциях создания и уничтожения связей для этой модели нет необходимости потому, что все связи предопределены заранее древовидной структурой отношений. Операция "найти" сводится к одной из трех процедур обхода дерева.
При использовании иерархической модели актуальной является проблема отслеживания связей, хотя и в более простом варианте. К возможным недостаткам иерархической модели можно отнести вероятную асимметрию отношений между сущностями предметной области БД и неудобство в отображении горизонтальных связей, которые нужно выражать через вертикальные связи.
Информация и данные
Прежде чем перейти к обсуждению понятия информационной системы (ИС), попытаемся выяснить, что же понимается под словом информация. Ответить на этот вопрос и просто, и сложно: слово "информация" связано с широким кругом понятий, в том числе и определенных строго математически (информация по Шеннону, например).Содержательная же сторона понятия "информация" очень многогранна и не имеет четких семантических границ. Однако всегда можно сказать, что можно с ней делать. Именно ответ на этот вопрос чаще всего и интересует как системных аналитиков и разработчиков (ИС), так и пользователей информации (ее основных потребителей).
С точки зрения как пользователей, так и разработчиков ИС, у информации есть одно важное свойство - она является единицей данных, подлежащих обработке. Обычно информация поступает потребителю именно в виде данных: таблиц, графиков, рисунков, фильмов, устных сообщений, которые фиксируют в себе информацию определенной структуры и типа. Таким образом, данные выступают как способ представления информации в определенной, фиксированной форме, пригодной для обработки, хранения и передачи. Хотя очень часто термины "информация" и "данные" выступают как синонимы (особенно в среде разработчиков ИС), следует помнить об этом их существенном отличии. Именно в данных информация обретает интерпретацию в конкретной ИС.
При упоминании о "форме" представления информации следует сказать и еще об одном, "человеческом" свойстве информации - ее восприятии различными категориями людей. Данные могут быть сгруппированы совместно в документ. Документ может иметь или не иметь определенную внутреннюю структуру. Данные могут быть отображены на экране дисплея компьютера. Документы могут иметь аудио- или видеоформу. Разрабатывая ИС, никогда не следует забывать, для кого они (системы) создаются и кто будет их использовать (воспринимать информацию в них). Форма представления информации в ИС определяет не только ее "дружелюбие", но также и категории пользователей. ИС создаются для конкретных групп пользователей, т.е. они, как правило, проблемно-ориентированны.
Информация как социальный ресурс
За три последних десятилетия стало общепризнанным, что информация является не менее важным ресурсом человеческого общества, чем сырье, энергия и пища. Можно утверждать, что практически в любом виде человеческой деятельности требуется удовлетворение информационных потребностей в той или иной степени. Так, например, собираясь на улицу, мы всегда хотим получить информацию о погоде. Большинство из нас в том или ином виде ежедневно получают различную информацию из газет, радио, телепередач, Интернета. Не говоря уже об источниках профессиональной информации.Развитие систем связи и коммуникаций привело к усложнению и дифференциации информационных процессов в человеческом обществе. Способность накапливать информацию и обеспечивать эффективный доступ к ней становится определяющим фактором не только развития человеческого общества, но и поддержания его жизнеспособности. Быстрый рост объемов информации, закрепленной на внешних по отношению к человеку носителях, привел к появлению новых общественных институтов (библиотеки, архивы, пресса, вычислительные центры и т. д.) и специальных систем (службы научно-технической информации, справочные службы, глобальные информационные компьютерные сети).
Развитие средств вычислительной техники и информационных технологий открыло новые возможности и способы хранения, представления и поиска информации, в частности, создание вычислительных систем, "доступных по требованию" - т.е. вычислительные ресурсы становятся таким же доступным ресурсом для потребления человеком, как электроэнергия, природный газ, вода.
Таким образом, резко возрастают требования к качеству и надежности проектирования систем для работы с информацией, представляемой в электронном виде.
Информационная модель данных
На рис. 1.6 иллюстрируется общее содержание понятия модели данных, сложившееся к настоящему времени.
Рис. 1.6. Представление об информационной модели данных
Объектами информационной модели являются сущности реального мира из предметной области. Иногда их называют итемами, чтобы подчеркнуть их целостность. Свойства объектов (сущностей) называют атрибутами. Сущности вступают в связи друг с другом через свои атрибуты. Эти три компонента информационной модели представляют субъективные средства описания модели, которые после определенной формализации дают внешнюю схему данных БД ИС.
Информационные системы
Основной целью создания ИС является удовлетворение информационных потребностей пользователей путем предоставления необходимой им информации на основе хранимых данных. Потребность в информации как таковой не исчерпывает понятия информационных потребностей. Обычно в понятие информационных потребностей включают определенные требования к качеству информационного обслуживания и поведению системы в целом (производительность, актуальность и надежность данных, ориентация на пользователя и ряд других, о чем мы поговорим позже).Определение 2. Под информационной системой понимается организационная совокупность технических и обеспечивающих средств, технологических процессов и кадров, реализующих функции сбора, обработки, хранения, поиска, выдачи и передачи информации.
Необходимость повышения производительности труда в сфере информационной деятельности приводит к тому, что в качестве внешних средств хранения и быстрого доступа к информации чаще всего используются средства вычислительной техники (цифровой и аналоговой) на основе компьютеров. Современные ИС - сложные комплексы аппаратных и программных средств, технологии и персонала, которые еще называют автоматизированными информационными системами. Структурно ИС включают в себя аппаратное (hardware), программное (software), коммуникационное (netware), промежуточного слоя (middleware), лингвистическое и организационно-технологическое обеспечение.
Аппаратное обеспечение ИС включает в себя широкий набор средств вычислительной техники, средства передачи данных, а также целый ряд специальных технических устройств (устройства графического отображения информации, аудио- и видеоустройства, средства речевого ввода и т.д.). Аппаратное обеспечение является основой любой ИС.
Коммуникационное (сетевое) обеспечение включает в себя комплекс аппаратных сетевых коммуникаций и программных средств поддержки коммуникаций в ИС. Оно имеет существенное значение при создании распределенных ИС и ИС на основе Интернета. При создании распределенных ИС огромную роль также играет программное обеспечение промежуточного слоя, состоящее из набора программных средств (служб и сервисов), которые управляют взаимодействием распределенных объектов в системе.
Программное обеспечение ИС обеспечивает реализацию функций ввода данных, их размещения на машиночитаемых носителях, модификации данных, доступ к данным, поддержку функционирования оборудования. Программное обеспечение можно разделить на системное (которое венчает процесс выбора аппаратно-программного решения, или платформы, как говорят в настоящее время) и пользовательское (которое применяется для решения задач удовлетворения потребностей пользователя в компьютерной среде, а именно, реализует бизнес-логику).
Лингвистическое обеспечение ИС предназначено для решения задач формализации смыслового содержания полнотекстовой и специальной информации для создания поискового образа данных (профиля). В классическом смысле обычно оно включает процедуры индексирования текстов, их классификацию и тематическую рубрикацию. Зачастую ИС, содержащие сложно-структурированную информацию, включают в себя тезаурусы терминов и понятий (средства поддержки метаданных). Сюда можно отнести и создание процессоров специализированных формальных языков конечных пользователей, например языков для манипулирования бухгалтерской информацией и т.д. Чаще всего работам по разработке лингвистического обеспечения не придается должного значения. Подобные упущения чаще всего ведут к неприятию пользователями самой системы и, как следствие, к ее закономерной гибели. Это относится в первую очередь к узко специализированным ИС.
По мере возрастания сложности и масштабов ИС важную роль начинает играть организационно-технологическое обеспечение, которое соединяет разнородные компоненты (аппаратуру, программы и персонал) в единую систему и обеспечивает процедуры ее управления и функционирования. Недооценка этой составляющей ИС чаще всего приводит к срыву сроков внедрения системы и вывода ее на производственные мощности.
На рис. 1.2 просуммированы в общих чертах функции ИС через ее основные структурные компоненты.
Рис. 1.2. Определение информационной системы
Итерационная процедура построения информационных систем
В чем состоит преимущество ориентации на автоматизацию основных бизнес-процессов при автоматизации организации или предприятия? Традиционно и повсеместно используемым подходом (особенно на начальных этапах развития информационной инфраструктуры организации) является применение так называемого позадачного метода решения задач автоматизации, направленного на решение достаточно простых и понятных руководству задач.Например, учет заказов, выписка счетов, подготовка документов. Конъюнктурное преимущество такого метода очевидно: достаточно быстро может быть получен результат, существование модной ныне ИТ-службы оправдано, внутренние инвестиции быстро вернулись. В принципе, с точки зрения системного анализа это является порочной практикой. Однако он существует, поскольку позволяет, с одной стороны, вроде бы не отставать от жизни (наличие ИС в организации зачастую является одним из определяющих факторов ее конкурентоспособности), а с другой - экономить денежные средства на автоматизации. Вышеуказанный подход позволяет использовать служащих с невысокой квалификацией. Рано или поздно это становится тормозом в развитии информационной инфраструктуры организации.
Низкая отдача уже существующей ИС организации на текущем этапе ее эксплуатации также становится тормозящим фактором. Изменение направлений бизнеса организации и ряд других факторов приводят к вопросу пересмотра отношения к ИС в организации, т.е. к извечному вопросу - переделать или начать с начала. Начать сначала всегда выгодней. Можно применить уже хорошо отработанные в информатике методики проектирования "сверху-вниз" или "снизу-верх". Однако рано или поздно опять встанет вопрос о соответствии требованиям сегодняшнего дня.
Даже в тех случаях реализации ИС, которые одобряются системным анализом, не удается избежать переделки ИС, т.к. она, как органическая часть производственного процесса, должна следовать и отвечать стратегическому генеральному бизнес-плану развития организации. Такой план всегда должен быть, если организация собирается долго жить в своем секторе рынка.
Разработчики ИС фактически всегда находятся в методике "из-середины" (midlle of design). Есть некоторая основа (уже созданная или создаваемая), и вокруг нее следует развиваться в различных направлениях, не сильно ломая сложившиеся традиции. Таким образом, постулируется итерационный подход в разработке и создании информационных систем. И, как следует из вышесказанного, он определяется не желанием теоретиков ИС, а жизненной необходимостью.
Основным подходом в таких переделках (так же, как и при создании) ИС является концепция реинжиниринга, суть которого сводится к постоянному моделированию информационных процессов и данных организации и их отображения в существующей системе.
Что является основной особенностью технологии реализации итерационного подхода разработки и сопровождения ИС? Основная особенность реализации концепции разработки ИС, ориентированной на интегрированные процессы, - это наличие или отсутствие сборочного конвейера, поскольку необходимо собирать воедино многие технологические процессы обработки информации. При объединении технологических процессов обработки информации увеличивается скорость прохождения информации в системе, принятие решений на основе информационных потоков становится частью процесса обработки информации (и более состоятельной), уменьшается иерархия управленческих структур.
Следует также иметь в виду, что наличие в организации корпоративной ИС зачастую меняет представление пользователей о том, как информация должна циркулировать в организации, что является еще одним важным стимулом модернизации ИС. ИС - составляющая и несущая часть пирамиды обработки информации. Поэтому в процессе разработки и реализации ИС приходится перестраивать как бизнес-процессы, так и бизнес-правила и их взаимодействие, что и составляет основу реинжиниринга.
Для того чтобы ИС жила долго и ее эксплуатация приносила ощутимую выгоду, необходимо тщательно проектировать и ее архитектуру, и ее составные компоненты, в частности базы данных, о которых пойдет речь ниже.
Разработчики ИС фактически всегда находятся в методике "из-середины" (midlle of design). Есть некоторая основа (уже созданная или создаваемая), и вокруг нее следует развиваться в различных направлениях, не сильно ломая сложившиеся традиции. Таким образом, постулируется итерационный подход в разработке и создании информационных систем. И, как следует из вышесказанного, он определяется не желанием теоретиков ИС, а жизненной необходимостью.
Основным подходом в таких переделках (так же, как и при создании) ИС является концепция реинжиниринга, суть которого сводится к постоянному моделированию информационных процессов и данных организации и их отображения в существующей системе.
Что является основной особенностью технологии реализации итерационного подхода разработки и сопровождения ИС? Основная особенность реализации концепции разработки ИС, ориентированной на интегрированные процессы, - это наличие или отсутствие сборочного конвейера, поскольку необходимо собирать воедино многие технологические процессы обработки информации. При объединении технологических процессов обработки информации увеличивается скорость прохождения информации в системе, принятие решений на основе информационных потоков становится частью процесса обработки информации (и более состоятельной), уменьшается иерархия управленческих структур.
Следует также иметь в виду, что наличие в организации корпоративной ИС зачастую меняет представление пользователей о том, как информация должна циркулировать в организации, что является еще одним важным стимулом модернизации ИС. ИС - составляющая и несущая часть пирамиды обработки информации. Поэтому в процессе разработки и реализации ИС приходится перестраивать как бизнес-процессы, так и бизнес-правила и их взаимодействие, что и составляет основу реинжиниринга.
Для того чтобы ИС жила долго и ее эксплуатация приносила ощутимую выгоду, необходимо тщательно проектировать и ее архитектуру, и ее составные компоненты, в частности базы данных, о которых пойдет речь ниже.
Концепция баз данных
Подавляющее большинство компьютеров, которые используются для аппаратного обеспечения создателями ИС, являются компьютерами фон Неймана. Основная идея, положенная в основу создания компьютера фон Неймана, состоит в том, что компьютер представляет собой вычислительную машину с загружаемым в его память кодом - программами и данными. В процессе своей работы такая машина интерпретирует код и различает программы (исполняемый код) и данные (неисполняемый код).Подавляющее большинство компьютеров, которые используются для аппаратного обеспечения создателями ИС, являются компьютерами фон Неймана. Основная идея, положенная в основу создания компьютера фон Неймана, состоит в том, что компьютер представляет собой вычислительную машину с загружаемым в его память кодом - программами и данными. В процессе своей работы такая машина интерпретирует код и различает программы (исполняемый код) и данные (неисполняемый код).
Идея повышения степени независимости обрабатывающих программ от способов хранения и содержания хранимых данных впервые была использована в концепции баз данных путем разделения логического и физического уровней хранения данных в 1964 году в исследованиях сотрудников фирмы IBM.
Что же принято понимать под базой данных? Базу данных в общем случае можно определить как унифицированную совокупность хранимых и воспроизводимых данных, используемых в рамках организации (Engles R.A., 1972 г.). Однако понятие базы данных не основывается в настоящее время на единой концепции, скорее это целое семейство связанных между собой понятий из области предметной области, программного и аппаратного обеспечения, анализа и моделирования данных и приложений. Мы дадим несколько определений базы данных.
Определение 3. База данных.
Для разработчика ИС существенным моментом при использовании концепции баз данных является то обстоятельство, что данные становятся определенным образом организованы, приобретают некую упорядоченность и внутреннюю структуру, а также то, что имеется некоторый набор унифицированных операций обработки данных и декларативных средств представления данных. К таким операциям следует отнести операции "Вставить" (Insert), "Добавить" (Add), "Удалить" (Delete) и ряд других. К декларативным средствам представления данных следует отнести языки определения данных. То есть использование данной концепции при создании ИС предполагает наличие языка определения данных и языка манипулирования данными, а также правил построения интерфейсов программ (приложений) с БД и пользователем.
Такое деление средств манипулирования данными и их представления является в определенной степени условным. Язык определения данных служит для описания логической структуры (схемы) БД, а в некоторых случаях и способов хранения и доступа к данным. Язык манипулирования данными предоставляет алгоритмические средства построения приложений для обработки сохраняемых в БД элементов данных.
Концепция трех схем
В рамках информационного моделирования существует несколько точек зрения (схем) на абстрагирование данных. С точки зрения пользователя (называемой внешней схемой), определение данных представляется в контексте языка предметной области. Структура данных и содержание меняется в зависимости от сферы деятельности и особенностей конкретного пользователя. С точки зрения компьютера (называемой внутренней схемой), данные определяются в терминах файловых структур для хранения и поиска. Структура данных в этом случае зависит от конкретной компьютерной технологии и от требований эффективности обработки данных.При моделировании информации на основе разработки только внешней и внутренней схем по-прежнему остаются трудными для решения проблемы избыточности и противоречивости данных. Хотя СУБД значительно расширяет возможности совместного использования данных, все же ее применение не гарантирует непротиворечивости определения данных.
Исследовательская группа по СУБД ANSI/X3/SPARC пришла к выводу, что для создания идеальной среды управления данными необходимо определение их с третьей, промежуточной точки зрения (концепция трех схем ANSI/X3/SPARC). Эта точка зрения (называемая концептуальной схемой) сводится к единообразному определению данных в рамках предметной области, не ориентированному на какое-либо конкретное использование их и не зависящему от того, как данные физически обрабатываются на компьютере (рис. 1.7).
Рис. 1.7. Концепция трех схем
Основной целью концептуальной схемы является выработка непротиворечивой интерпретации определения взаимосвязей данных для их объединения, совместного использования и управления целостностью данных.
С другой стороны, любая информационная модель данных определяется средствами поддержки модели данных, реализуемыми СУБД.
Модели вычислений
Взгляд на использование компьютеров меняется в процессе их применения в различных сферах человеческого труда: большие вычислительные центры с мощными компьютерами, средние по мощности ЭВМ для автоматизации технологических процессов, персональные компьютеры, компьютеры, объединенные сетью коммуникаций. Неизменным остается требование пользователей к вычислительным ресурсам для удовлетворения потребностей в информации - время процессора (быстродействие), оперативная память, дисковое пространство и т.п. Проблема совместного использования ресурсов является одной из ключевых проблем решения любых прикладных задач на ЭВМ, в том числе и создания ИС. Решение этой проблемы приводит к разработке новых компьютерных технологий, которые являются сложным синтезом изменений в аппаратном и программном обеспечении. Основой таких модификаций как аппаратного, так и программного обеспечения являются модели вычислений.Что принято понимать под моделью вычислений? Обычно под моделью вычислений подразумевают совокупность аппаратно-программных средств, схему их взаимодействия между собой и пользователями, т.е. постулируется ответ на вопросы, каким образом и какие вычислительные ресурсы используются в процессе выполнения вычислений. Поскольку понятие модели вычислений связано как и с аппаратным, так и с программным обеспечением, то нередко в качестве синонима слова модель используется слово архитектура. За всю историю развития вычислительной техники было предложено не так уж много моделей вычислений.
Централизованные вычисления:
Распределенные вычисления:
Исторически одной из первых моделей вычислений является модель с использованием централизованной хост-ЭВМ. В такой схеме вычислений пользователь получает доступ к вычислительным ресурсам ЭВМ через сеть неинтеллектуальных терминалов (т.е.
терминалов, не обладающих никакими вычислительными возможностями). Центральный компьютер полностью отвечает за взаимодействие с пользователем и управление данными в многопользовательской среде.
Преимуществом такой модели вычислений является их централизация. Централизованные системы позволяют совместно использовать вычислительные ресурсы (диски, принтеры, оперативную память) с высокой эффективностью, а также обеспечивать высокую надежность и актуальность хранимых данных.
Самым большим недостатком такой схемы вычислений является линейная зависимость вычислительной мощности центральной ЭВМ от числа пользователей и, как следствие, высокая стоимость аппаратуры и программного обеспечения. Несмотря на устойчивую тенденцию снижения стоимости оборудования, такие системы по-прежнему остаются одними из дорогостоящих (отношение "цена/производительность" остается достаточно высокой).
В 80-е годы прошлого века появились персональные компьютеры и рабочие станции. Независимые друг от друга, предоставляющие вычислительные возможности, которые сопоставимы с большими ЭВМ, доступные по цене широкому кругу потребителей (отношение "цена/производительность" в данном случае гораздо ниже, чем при использовании больших ЭВМ). Персональные компьютеры положили конец централизованному подходу в обработке данных и обозначили переход к распределенным вычислениям.
Преимуществом такой модели вычислений является их автономность в использовании вычислительных ресурсов, т.е. централизованное использование компьютера, но на рабочем месте и независимо от других таких же компьютеров. В данном случае можно подобрать персональный компьютер адекватно решаемому кругу задач.
Однако у независимых персональных вычислений есть и свои проблемы. Эти проблемы порождают распределенность данных (невозможность совместной работы с данными различных пользователей) по персональным компьютерам в случае, когда эти данные должны использоваться совместно в рамках одной организации. При этом выигрыш в отношении "цена/производительность" компенсируется потерями в производительности труда коллективов, работающих с распределенными таким образом данными.
Проблемы совместного использования данных, расположенных на персональных компьютерах, привели к разработке концепции локальной вычислительной сети, которая восстанавливает преимущества коллективных вычислений и сохраняет простоту использования персональных компьютеров. Наличие вычислительной сети компьютеров характерно для всех моделей распределенных вычислений.
Модель вычислений "файл-сервер" (или архитектура "файл-сервер") основывается на понятии сервера. Термин сервер имеет двойственный смысл. С одной стороны, сервер есть узел вычислительной сети (компьютер с сети), предназначенный для предоставления совместно используемых ресурсов и услуг, а с другой - программный компонент, предоставляющий общий функциональный сервис другим программным компонентам вычислительной сети.
Файловый сервер является обычно центральным узлом сети, на котором хранятся файлы коллективного пользования и который является также концентратором совместно используемых периферийных устройств (например, принтера или дискового накопителя большой емкости). Файловый сервер не принимает участия в обработке приложения. Он выполняет сетевой транспорт совместно используемых данных (часто пересылая файл целиком конечному пользователю).
Преимуществом такой модели является, несомненно, корпоративное использование территориально распределенных вычислительных ресурсов, имеющее одним из своих следствий создание глобальных вычислительных систем и новых технологий обмена информацией.
Однако у такой модели есть два крупных недостатка при разработке многопользовательских приложений. Интенсивный обмен данными (рост трафика сети) приводит к быстрому достижению ее пропускной способности и тем самым к снижению (из-за увеличения времени реакции приложения за счет времени ожидания) производительности многопользовательской системы.
Другая проблема - это обеспечение согласованности данных, т.е. одновременного разделения доступа к одним и тем же данным группой пользователей. Обычно файл блокируется для других пользователей, когда его начинает обрабатывать приложение.
В случае, когда часть файла реплицируется на конечный узел для обработки, снижается актуализация данных, что может быть неприемлемо для систем оперативной обработки информации.
Модель вычислений "клиент-сервер" явилась следующим шагом в развитии распределенных вычислений, объединив в себе преимущества коллективных вычислений в сети компьютеров с доступом к совместно используемым данным и высокие характеристики производительности вычислений с центральной ЭВМ. Основными понятиями данной модели являются сервер баз данных, клиентское приложение и сеть.
Основное назначение сервера баз данных - оптимальное управление разделяемыми ресурсами на уровне данных для множества клиентов. На этом уровне достаточно эффективно решаются задачи обеспечения согласованности данных, их актуальности, защиты и целостности.
Клиентское приложение является частью системы, которая обеспечивает интерфейс приложения с серверов баз данных. Логика приложения может быть полностью реализована на клиентской части системы, а обработку данных забирает на себя сервер баз данных.
Сеть и коммуникационное программное обеспечение являются средствами передачи данных. Реализация этой компоненты модели обеспечивает прозрачность сервера баз данных по отношению к клиенту.
Рис. 1.10. Преимущества и недостатки модели вычислений "клиент-сервер"
Несмотря на то, что модель вычислений "клиент-сервер" является высокопроизводительной распределенной моделью вычислений, она, помимо очевидных преимуществ, имеет присущие ей недостатки (рис. 1.10). Кроме того, другие модели вычислений также продолжают развиваться, обеспечивая приемлемые значения отношения "цена-производительность".
Модель "вычисления по требованию" или GRID является в настоящее время одной из перспективных распределенных моделей вычислений. Суть ее состоит в использовании вычислительных ресурсов, расположенных в локальной или глобальной вычислительной сети, аналогично тому, как мы в быту используем электричество, совершенно не отдавая себе отчета в том, с какой электростанции оно поступает к нам в дом.
В этой модели вычислений заявленные в сети GRID вычислительные ресурсы (компьютеры или кластеры ЭВМ) предоставляют свои свободные вычислительные ресурсы согласно правилам обслуживания заданий в очереди. Таким образом, находясь в России, вы можете запустить свою задачу на компьютере в Австралии, совершенно об этом не зная.
В этой лекции мы рассмотрели ряд основных понятий и терминов, которые потребуются проектировщику реляционных баз данных в процессе решения им своих профессиональных задач. В последующих лекциях мы последовательно и детально рассмотрим основные профессиональные задачи проектировщика реляционных баз данных.
Литература: [1], [2], [10], [12], [21], [29], [34], [36], [40], [41], [47].
Общие принципы классификации СУБД
Очень часто СУБД классифицируются по типу модели данных, которую они поддерживают. Следовательно, различают СУБД сетевые, иерархические и реляционные. Однако в практике обработки данных СУБД характеризуются по их способности поддерживать определенный тип БД. В самом общем виде БД подразделяют на:Так, СУБД CDS/ISIS в первую очередь ориентирована на поддержку работы с документом, который состоит из определенного числа рубрик, проиндексированных по тезаурусу ключевых слов. СУБД ADABAS хорошо подходит для организации фактографических БД, а СУБД ORACLE - для БД смешанного типа. Во избежание несуразностей с использованием определенной модели данных, БД, за редким исключением, целесообразно классифицировать по типу используемой модели в СУБД. Отметим, что классификация БД далеко не завершенная область исследований: попытки ввести новые типы БД продолжаются (активные, дедуктивные, нечеткие реляционные, графические БД и т.д.).
Во многих случаях для разработчиков ИС бывает важно деление СУБД (и БД) по характеру обработки: на централизованные и распределенные. При использовании распределенной обработки следует обратить внимание на характер обработки транзакций, т.к. последние оказывают существенное влияние на производительность системы. Под транзакцией в самом общем случае понимают единицу работы, требуемой пользователем от БД, независимо от характера обработки. Чаще всего в результате обработки транзакции реализуется запрос пользователя либо на выборку данных из БД, либо на обновление БД, либо на выполнение каких-то иных действий над БД. При этом предполагается, что выполнение запроса сопровождается выполнением комплекса внутрисистемных действий СУБД, направленных на поддержание целостности данных, разграничение доступа и т.п.
Существуют различные концептуальные подходы к обработке транзакций при распределенной обработке. Принципиальным здесь является не только вопрос как, но и где локализуется обработка транзакции: на файлах компьютера конечного пользователя или на выделенном в сети компьютере. От выбора той или иной концепции будет зависеть время отклика системы на запрос пользователя. Параметр "время отклика системы на запрос пользователя" очень часто выступает в качестве определяющего или желательного параметра разрабатываемой системы. Например, для распределенной системы бронирования авиабилетов для крупнейших мировых авиакомпаний этот параметр является существенным и закладывается в проектное решение как не превышающий 30-45 секунд.
Обзор основных моделей данных
Тремя основными типами моделей структурированных данных являются иерархическая, сетевая и реляционная. Первые две из них основаны на представлении информации об объектах в виде плоского графа.Определение понятия информации
Теперь мы готовы дать следующее определение информации в применении к ИС.Определение 1. Информация есть данные, которым придается некоторый смысл (интерпретация) в конкретной ситуации в рамках некоторой системы понятий. Информация представляется посредством кодирования данных и извлекается путем их декодирования и интерпретации.
В этом определении фиксируется три основных преобразования информации и данных в процессе их обработки в ИС: информация-данные, данные-данные, данные-информация.
Рассмотрим пример с классической ИС - библиотекой. Книга поступает в библиотеку. На нее заводятся библиографические карточки (выполняется преобразование информация-данные). Библиографические карточки размещаются в каталогах в соответствии с внутренними библиотечными процедурами систематизации (выполняется преобразование "данные-данные"). Читатели работают с каталогами библиографических карточек в поисках нужных им книг (выполняется преобразование данные-информация). Аналогичным образом можно рассмотреть процесс продажи товара через склад и многие другие сферы человеческой деятельности.
Заметим, что вопрос о преобразовании информация-информация, которое также имеет прямое отношение к ИС, не фигурирует явно в данном рассмотрении. Это преобразование имеет прямое отношение к производству новых знаний. Производство новых знаний относится к разработке систем искусственного интеллекта и не затрагивается непосредственно в данных лекциях.
На рис. 1.1 представлены две стороны определения понятия информации: функциональная и представительная. Первая в общих чертах определяет круг действий над информацией, а вторая - результат выполнения этих действий.
Рис. 1.1. Содержание термина "информация"
При разработке ИС важно отличать собственно генерацию информации и поддержку ее актуальности (соответствия текущему моменту) от процедур ее оформления для потребления пользователем.
Основные подходы к обработке информации в автоматизированных информационных системах
Одним из главных вопросов разработки программного обеспечения ИС (и программирования как самостоятельной дисциплины) является вопрос о соотнесении программ и данных, ибо решение этого вопроса, в конечном счете, определяет выбор алгоритмов обработки информации, аппаратных средств и технологической платформы. Фундаментальным принципом в решении вопроса о соотнесении программ и данных является концепция независимости прикладных программ от данных, и неважно, какая обработка данных предполагается: централизованная или распределенная. Суть этой концепции состоит не столько в отделении программ от данных, сколько в рассмотрении их как самостоятельных взаимодействующих объектов.Одной из последних модификаций этого принципа является концепция независимости прикладных программ от данных вместе с процедурами их обработки (объектно-ориентированный подход в программировании), который позволяет решить ряд вопросов обработки данных, связанных с интерпретацией семантического смысла данных.
Торжество концепции независимости программ от данных привело к формированию в 1962 году концепции базы данных (БД) и созданию на ее основе метода баз данных для решения задач обработки информации. До середины 60-х годов прошлого века основной концепцией построения программного обеспечения являлась концепция файловой системы и так называемый позадачный метод. Такой подход по-прежнему остается доминирующим в разработке и функционировании несущих операционных платформ. В конце 80-х годов прошлого века была предложена концепция объектно-ориентированных баз данных и объектно-ориентированный подход разработки программ на основе обработки событий. На рис. 1.3 представлены основные черты для каждой из указанных выше концепций. На рис. 1.4 проведено сопоставление основных методов обработки данных.
Рис. 1.3. Основные концепции обработки информации
Рис. 1.4. Основные методы обработки информации
Основной смысл объектной технологии состоит в том, что программы рассматриваются как совокупность объектов. Объекту присущи следующие свойства:
Основные типы моделей и их эквивалентность
Наличие в СУБД определенной, допустимой структуры данных приводит к понятию баз структурированных данных, то есть данные в таких БД должны быть представлены как совокупность взаимосвязанных элементов. Если допустить возможность порождения новых типов и динамический процесс установления связей (во время появления объекта в БД), то мы придем к понятию баз неструктурированных данных. Допустимы и промежуточные варианты, которые носят название БД с частично детерминированной схемой. Такое деление БД с точки зрения степени структурированности сохраняемых данных оказывается существенным моментом при выборе несущей СУБД для реализации ИС, поскольку конкретная СУБД обычно поддерживает определенную модель данных. С другой стороны, следует иметь в виду, что для каждого из приведенных типов БД используются соответствующие модели данных, т.е. существует некоторое множество моделей данных.В настоящее время для баз структурированных данных различают три основных типа логических моделей данных в зависимости от характера поддерживаемых ими связей между элементами данных - сетевую, иерархическую и реляционную. Классифицирующими признаками в этих моделях являются: степень жесткости (фиксации) связи, математическое представление структуры модели и допустимые типы данных (см. таблицу 1.1). Допустимые типы данных будут обсуждаться далее при изучении реляционной модели.
| Сетевая | Полужесткие связи | Произвольный граф |
| Иерархическая | Жесткие связи | Древовидная структура |
| Реляционная | Изменчивые связи | Плоский файл |
Рис. 1.8 иллюстрирует особенности каждой модели данных. При сопоставлении моделей следует помнить, что все они теоретически эквивалентны. Эквивалентность моделей состоит в том, что они могут быть сведены одна к другой путем формальных преобразований. Подробное доказательство этого факта можно найти в классической монографии Дж. Мартина по БД. Суть доказательства состоит в отказе от принципа избыточности данных, то есть разрешается дублировать данные в узлах представления. Тогда преобразование одной модели в другую получается простым удвоением вершин соответствующего представления в цепочке моделей "сетевая-иерархическая-реляционная".
Рис. 1.8. Основные типы моделей данных
Понятие о модели данных
В предыдущих разделах все время подчеркивалась роль представления данных в решении задач обработки информации (принцип независимости программ от данных, концепция баз данных и т.д.). Представление информации с помощью данных требует унифицированного подхода к понятию данных как независимого объекта моделирования. Поэтому для разработчика ИС выбор соответствующей модели данных является одной из самых важных проблем. Выбор модели данных влечет за собой выбор средств анализа предметной области (ПО БД) как сферы реального мира, подлежащего изучению и обработке средствами ВТ, - об этом мы будем говорить в следующей лекции. В конечном счете такой выбор делает разработчика "заложником" той или иной информационной технологии создания информационных систем с базами данных.Таким образом, понятие модели данных является одним из фундаментальных понятий информатики, от которого во многом зависят механизмы реализации ИС как программно-аппаратного комплекса.
Что же такое модели данных? В самом общем случае модель данных - это логическое представление данных и совокупность операций над ними.
Определение 5. Модель данных (Data Model) есть логическая структура данных, которая представляет присущие этим данным свойства, не зависимые от аппаратного и программного обеспечения и не связанные с функционированием компьютера.
Можно рассмотреть несколько аспектов моделирования в обработке данных:
Физическая модель определяется особенностями устройств хранения информации и связи. Поскольку мы в наших лекциях не занимаемся разработкой методов доступа и СУБД, то вопросы физического моделирования данных рассматриваться не будут.
Сетевая модель данных
Остановимся на понятии сетевой структуры, положенной в основу сетевой модели данных. Рассмотрим отношение между следующими объектами: Студенческий коллектив, Студенческая группа, Комната в общежитии и Студент. Взаимосвязь между этими объектами не является иерархической, так как порожденный элемент Студент имеет два исходных - Студенческая группа и Комната в общежитии. Такие отношения, когда порожденный элемент имеет более одного исходного, описываются в виде сетевой структуры. В такой структуре любой элемент может быть связан с любым другим элементом.Как и в случае иерархической модели, сетевую структуру можно описать в терминах исходных и порождаемых узлов, а также представить ее таким образом, чтобы порожденные узлы располагались ниже исходных. При рассмотрении некоторых сетевых структур можно говорить об уровнях. Так, рассмотренная выше сетевая структура имеет три уровня.
Рассмотрим, как в сетевой модели будут представлены взаимосвязи между объектами. В нашем примере присутствуют два вида взаимосвязей: 1:M (Учебная группа - Студент) и M:1 (Студент - Комната в общежитии). Сетевые структуры, которые имеют такие связи между исходными и порожденными узлами, порожденными и исходными узлами, относят к простым сетевым структурам. Сложной сетевой структурой называют такую структуру, в которой присутствует хотя бы одна связь типа N:M. Примером такой связи является отношение Студент - Преподаватель. Такое разделение сетевых структур обусловлено технологическими сложностями реализации взаимосвязи N:M. Причем некоторые СУБД не обрабатывают сложных сетевых структур (СЕТОР, DNS, DBMS).
База данных с сетевой структурой состоит из нескольких областей. Каждая область состоит из записей, которые состоят из полей. Объединение записей в логическую структуру возможно не только по областям, но и с помощью наборов данных. По существу набор данных - это поименованное двухуровневое дерево, которое является основой для построения многоуровневых деревьев. Сама база данных состоит из некоторой совокупности наборов данных.
Набор данных - это экземпляр поименованной совокупности записей. Каждый тип набора представляет собой отношение между двумя или несколькими типами записей. Для каждого набора данных один тип записи может быть объявлен владельцем, а один или несколько типов других записей - членами набора. Набор данных, например, можно использовать для объединения записей о студентах одной группы. Тогда тип набора можно определить как состав группы с типом записи владельца. Например, Учебная группа с типом записей членов Студент: Учебная группа (запись-владельца) - Студент (совокупность записей о сту дентах в данной группе).
Набор данных имеет следующие свойства:
Необходимо различать тип и экземпляр набора. Предварительно поясним различие между понятиями "тип" и "экземпляр" записи. Например, Студент является типом записи, а строка, содержащая информацию о конкретном студенте, является экземпляром типа записи Студент. Аналогичное различие существует между типом и экземпляром набора данных. Например, тип набора Состав группы, а его экземпляр содержит один экземпляр типа записи владельца Учебная группа и N экземпляров типа записи-члена Студент. Определенный экземпляр типа записи-члена не может одновременно принадлежать более чем одному экземпляру типа записи-владельца. Уникальность владельца типа набора является обязательным элементом сетевой модели данных. С этой точки зрения иерархическая модель является частным случаем сетевой модели данных.
Концепция сетевой модели данных связана с именем Ч. Бахмана, известного специалиста в области обработки данных, который оказал определяющее влияние на создание проекта DBTG CODASYL (1971 год). Сетевая модель данных является моделью объектов-связей, где допускаются только бинарные связи типа "многие-к-одному", что позволяет использовать для представления данных простую модель ориентированных графов. В некоторых определениях сетевой модели допускаются связи типа "многие-ко-многим", но требование бинарности связи остается в силе.
Для сетевой модели не существует общепринятой терминологии. Далее используется сложившая к настоящему времени группа понятий и терминов, которые используются для описания элементов сетевой модели.
Для моделирования представления данных в сетевой модели используются следующие элементы данных:
На рис. 1.9 приведен фрагмент описания схемы БД (описание статьи записи) на примере записи из БД "Кадры", предназначенной для автоматизации работы отдела кадров организации. Для описания записи используется язык описания данных СODASYL. Описание схемы БД в CODASYL состоит из четырех статей:
Рис. 1.9. Описание записис в сетевой модели данных
Элементы данных сетевой модели допускают обработку следующими операциями, множество которых составляет язык манипулирования данными:
В модели CODASYL существует набор дополнительных операций по обслуживанию БД, который здесь не рассматривается.
Очень часто к недостаткам сетевого подхода в БД относят как сложность самой модели данных, так и сложность освоения средств манипулирования данными в ней. Практически, при анализе ПО БД и программировании особенно тщательно приходится отлеживать цепочки связанных групповыми отношениями данных при операциях вставки, обновления и удаления. Однако действительный источник сложности сетевой модели данных состоит в диапазоне предоставляемых моделью конструкций для представления информации и набора операции для манипулирования этими конструкциями.
Системы управления базами данных
В ситуации применения концепции базы данных для создания ИС естественным образом возникает вопрос - а кто или что должно все это поддерживать? Таким образом, встает вопрос о Системе управления базой данных (СУБД). СУБД являются сложными программными системами, работающими на различных операционных платформах. Именно СУБД должна предоставить средства определения и манипулирования данными, сделав данные независимыми от прикладных программ, их использующих. В последнее время набирает обороты концепция машин баз данных, которая предполагает аппаратную реализацию некоторых процедур обработки данных.Однако после признания концепции БД прошло почти четыре года, прежде чем в 1966 году была создана первая СУБД. На рис. 1.5 представлены основные функции СУБД.
Рис. 1.5. Основные функции СУБД
Определение 4. Системой управления базами данных (Data-base Management System) называется совокупность программных средств, необходимых для использования базы данных и предоставляющих разработчикам и пользователям множество различных представлений данных.
Основы проектирования реляционных баз данных
Бизнес-модель процессов (иерархия функций системы)
Бизнес-модель процессов предназначена для описания процессов и функций системы в предметной области базы данных. Бизнес-модель чаще всего документируется в соответствии с методологией (нотацией) IDEF0 и представляется в виде совокупности иерархически упорядоченных и взаимосвязанных диаграмм (IDEF0-диаграмм). Каждая диаграмма является единицей описания системы и расположена на отдельном листе. IDEF0-диаграммы включают в себя следующие диаграммы:Контекстная диаграмма является вершиной иерархической структуры диаграмм и представляет самое общее описание системы и ее взаимодействия с внешней средой.
Дальнейшее описание системы строится на основе последовательного разбиения функциональности системы на более детальные фрагменты. Диаграммы, которые описывают каждый из функциональных фрагментов системы, называются диаграммами декомпозиции.
Диаграмма дерева узлов показывает иерархическую структуру функций, не отображая взаимосвязи между ними.
Диаграммы "только для экспозиции" представляют, по сути, копии стандартных диаграмм, но не включаются в анализ синтаксиса модели. Они предназначены для демонстрации иных точек зрения на работы, для отображения деталей, которые не поддерживаются явно синтаксисом модели.
Основными элементами IDEF0-диаграмм являются работы, входные и выходные параметры, управление, механизмы и вызов.
Работы (Activity) обозначают процессы, функции или задачи, которые реализуются в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников и именуются отглагольными существительными. Все диаграммы декомпозиции содержат родственные работы, имеющие общую родительскую работу.
Взаимодействие работ между собой и с внешними миром показано стрелками. Стрелки (Arrow) именуются существительными и могут обозначать на диаграмме вход, выход, управление, механизм и вызов.
Вход (Input) - это материалы или информация, которые используются или преобразуются работой для получения результата (выхода).
Стрелка входа рисуется как стрелка, входящая в левую грань работы.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая рисуется как стрелка, входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой.
Выход (Output) - это материалы или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как стрелка, выходящая из правой грани работы.
Механизм - это ресурсы, которые выполняют работу (персонал, станки, устройства). Стрелка механизма рисуется как стрелка, входящая в нижнюю грань работы. Механизмы могут не изображаться.
Вызов (Call) - это специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как стрелка, исходящая из нижней грани работы. Стрелка вызова указывает, что некоторая работа выполняется за пределами моделируемой системы.
На рис. 2.9 - 2.11 приведены примеры контекстной диаграммы, диаграммы декомпозиции и диаграммы дерева узлов процесса изготовления изделия.
Рис. 2.9. Контекстная диаграмма процесса изготовления изделия
Рис. 2.10. Диаграмма декомпозиции процесса изготовления изделия
Рис. 2.11. Диаграмма дерева узлов процесса изготовления изделия
На диаграмме дерева узлов последний уровень декомпозиции показан в виде списка.
Стрелка входа рисуется как стрелка, входящая в левую грань работы.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая рисуется как стрелка, входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой.
Выход (Output) - это материалы или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как стрелка, выходящая из правой грани работы.
Механизм - это ресурсы, которые выполняют работу (персонал, станки, устройства). Стрелка механизма рисуется как стрелка, входящая в нижнюю грань работы. Механизмы могут не изображаться.
Вызов (Call) - это специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как стрелка, исходящая из нижней грани работы. Стрелка вызова указывает, что некоторая работа выполняется за пределами моделируемой системы.
На рис. 2.9 - 2.11 приведены примеры контекстной диаграммы, диаграммы декомпозиции и диаграммы дерева узлов процесса изготовления изделия.
Рис. 2.9. Контекстная диаграмма процесса изготовления изделия
Рис. 2.10. Диаграмма декомпозиции процесса изготовления изделия
Рис. 2.11. Диаграмма дерева узлов процесса изготовления изделия
На диаграмме дерева узлов последний уровень декомпозиции показан в виде списка.
Диаграммы "сущность-связь"
Типичной формой документирования информационной модели предметной области являются диаграммы "сущность-связь" (ER-диаграммы). ER-диаграмма позволяет графически представить все элементы информационной модели согласно простым, интуитивно понятным, но строго определенным правилам - нотациям. Далее мы будем пользоваться условными обозначениями, принятыми в методологии информационного проектирования.Построение ER-диаграмм, как правило, ведется с использованием CASE-средств. Выбор CASE-средств и способы работы с ними в настоящем курсе не обсуждаются.
Документирование доменов
Домены назначаются аналитиками и фиксируются в специальном документе - словаре данных (Data Dictionary). На стадиях разработки логической и физической моделей реляционной базы данных домены уточняются в сущностях на ER-диаграмме.Проектировщик базы данных должен тщательным образом изучить домены каждого атрибута с точки зрения их реализуемости в СУБД, с участием аналитиков внести в них изменения, если условие реализуемости не выполняется. При этом проектировщик руководствуется следующим:
Рис. 2.5. Визуализация определения доменов атрибутов на ER-диаграмме при создании физической модели реляционной базы данных
Документирование отношений (связей)
Отношение (связь) сущностей на ER-диаграмме изображается линией, соединяющей эти сущности.Степень связи изображается с помощью символа "птичья лапка"1, указывающего на то, что в связи участвует много (N) экземпляров сущности, и одинарной горизонтальной чертой, указывающей на то, что в связи участвует один экземпляр сущности.
Необязательный класс принадлежности сущности к связи изображается с помощью кружочка на линии отношения рядом с сущностью, обязательный класс принадлежности - с помощью вертикальной черты на линии отношения рядом с сущностью.
Отношение читается вдоль линии либо слева направо, либо справа налево. На рис. 2.6 представлено следующее отношение: каждая специальность по образованию должна быть зарегистрирована за определенным физическим лицом (персоной), физическое лицо может иметь одну или более специальностей по образованию.
Рис. 2.6. Представление отношения между двумя сущностями на ER-диаграмме
Как правило, отношения на ER-диаграммах именуются с обеих сторон.
Рис. 2.7. Связанные сущности с названием сторон
Документирование супертипов и подтипов
Супертипы и подтипы, так же как и сущности, обозначаются на ER-диаграмме с помощью прямоугольников. Отношения между ними изображаются с помощью "вилки", имеющей в точке ветвления полукруг.
Рис. 2.8. Изображение супертипа Person с двумя подтипами Head и Employee
Супертип Person (Персона) содержит общие для своих подтипов Head (Руководитель) и Employee (Служащий) атрибуты. Подтипы содержат только атрибуты, характерные для выделенных категорий. Предложенная конструкция реализует отношение подчиненности в иерархии организации согласно ее штатному расписанию.
Изучив и проверив качество информационной модели данных предметной области, представленной в виде набора ER-диаграмм, проектировщик базы данных может приступать к созданию логической модели базы данных.
Документирование сущностей и атрибутов
Сущность на ER-диаграмме представляется прямоугольником с именем в верхней части. Будем использовать английские слова для именования элементов модели.
Рис. 2.3. Представление сущности Person (персонал) на ER-диаграмме
Рис. 2.4. Представление сущности Person с атрибутами и уникальным идентификатором сущности
В прямоугольнике перечисляются атрибуты сущности, при этом атрибуты, составляющие уникальный идентификатор сущности, подчеркиваются.
Информационная модель предметной области базы данных
Одним из ключевых моментов создания ИС с целью автоматизации информационных процессов организации является всестороннее изучение объектов автоматизации, их свойств, взаимоотношений между этими объектами и представление полученной информации в виде информационной модели данных.Информационная модель данных предназначена для представления семантики предметной области в терминах субъективных средств описания - сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д.
Информационная модель предметной области базы данных содержит следующие основные конструкции:
Контроль качества результатов анализа предметной области
Предположим, что проектировщик баз данных получил от аналитиков набор материалов с результатами анализа предметной области базы данных. Задача проектировщика - произвести контроль качества предоставленных результатов анализа в целях обеспечения их полноты и достоверности.Первое, что необходимо сделать, - составить перечень полученных документов и проверить, все ли необходимые документы присутствуют. Проектировщику должны быть представлены: (а) информационная модель предметной области базы данных; (б) совокупность частных моделей, которые относятся к функциональной модели предметной области базы данных; (в) общесистемные требования и решения. В то же время надо помнить, что не все конструкции могут оказаться нужными для решения задач проектирования. Так, например, диаграмма потоков данных непосредственно влияет на принятие решения о числе баз данных, подлежащих реализации в рамках системы. И если уже решено, что база данных будет одна, то принимать во внимание эту диаграмму не нужно. Также часто обходятся без диаграммы жизненных циклов сущностей и диаграммы состояний.
Далее проектировщик должен классифицировать представленные модели по типам и для каждой модели проверить выполнение присущих ей правил.
Существуют формальные и неформальные процедуры проверки результатов моделирования предметной области.
Формальные процедуры основываются на формализации общих знаний о моделях предметной области, в частности на: формальных механизмах, посредством которых представляются данные и процессы системы; формах документирования моделей - диаграммах; методологии графического представления диаграмм (нотациях). В таблице 2.1 приведен перечень моделей, используемых для моделирования данных на различных стадиях жизненного цикла создания ИС, типичные формы документирования моделей - диаграммы - и наиболее популярные методологии (нотации).
| Информационная модель предметной области | |||
| Анализ предметной области | Модели данных | Диаграммы "сущность-связь" (ERD) | CHEF, Martin, Bachman, IDEFXIX, Shlaer & Mellor, Merise, IEM |
| Диаграммы модели данных (DMD) | Martin, Bachman | ||
| Диаграммы структур данных (DSD) | Jackson | ||
| Диаграммы логических структур данных (LDS) | SSADM | ||
| Диаграммы UML | OOA&D | ||
| Функциональные модели предметной области | |||
| Модели процессов | Диаграммы модели бизнес-процессов (контекстная диаграмма, диаграмма декомпозиции, диаграмма дерева узлов | IDEF0, IDEF3 | |
| Диаграммы потоков данных | Yuordan/DeMarco, Gane & Sarson, SSADM | ||
| Графы преобразований | Ward & Mellor, Gane & Sarson, Hatley | ||
| Диаграммы UML | OOA&D | ||
| Модели состояний | Диаграммы состояний (STD) | Ward & Mellor, Hatley | |
| Диаграммы жизненного цикла (ELH) | SSADM | ||
| Диаграммы UML | OOA&D | ||
| Проектирование | Модели процессов проектирования | Структурные схемы (STC) | Youtdan/Constantine Page-Jones |
| Диаграммы UML | OOA&D | ||
| Реализация | Диаграммы UML | OOA&D | |
Как видно из таблицы, не существует единой модели, в рамках которой можно представить весь жизненный цикл системы. Так, стадия анализа предметной области системы представляется с помощью трех типов моделей:
Несмотря на то, что каждая из диаграмм может быть представлена с помощью широкого спектра нотаций, все они в рамках определенной диаграммы имеют общие основные черты. Ниже приведены правила, которыми должен руководствоваться проектировщик в ходе формальной проверки правильности представленных моделей.
На диаграммах "сущность-связь" должны быть представлены сущности, связи, степени связи, классы принадлежности сущности, неопределенные связи, супертипы/подтипы сущности. При этом каждая сущность и отношение должны быть поименованы и занесены в словарь данных; каждая сущность может появиться на диаграмме только один раз; каждая сущность должна вступать в отношение (отсутствие "висящих" сущностей), и каждое отношение должно иметь сущности (отсутствие "висящих" отношений). Поэтому проектировщик базы данных должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые, вероятнее всего, будут определять уникальный ключ связи.
Проектировщик базы данных должен проконтролировать, чтобы в информационной модели предметной области для каждого атрибута сущностей был определен домен. Следует понимать, что определение домена, даваемое аналитиками, носит самый общий характер (число, текст, дата, графика и т.д.), и будет далее уточнено при проектировании. На этом этапе важно, чтобы домен был определен.
На диаграммах модели бизнес-процессов должны быть представлены работы, вход, выход, управление и механизмы. При этом все элементы должны быть поименованы; все работы должны получаться путем функциональной декомпозиции некоторой более крупной работы; для каждой работы должно быть задано управление.
На диаграммах потока данных должны быть представлены внешние сущности (источники и потребители данных), процессы обработки данных, конкурирующие процессы, хранилища данных, потоки данных, указатели ветвления процессов. При этом все процессы должны быть пронумерованы: исходный (начальный) процесс должен иметь номер 0; процессы более низких уровней - 1.1, 1.2, и т.д.; 1.1.1, 1.1.2, и т.д.
На диаграммах жизненного цикла сущностей и диаграммах состояний должны быть представлены состояния, переходы и внешние переходы. При этом на диаграммах должно присутствовать начальное состояние, из которого получаются все остальные состояния. В конечное состояние можно попасть из любого состояния. Запрещается одновременно переход в два состояния; каждый переход имеет условие и действие, которые указываются рядом с переходом.
Таким образом, формальные процедуры проверки нацелены на проверку таких аспектов анализа, как: наличие у каждой сущности уникального идентификатора; наличие функции, создающей экземпляры сущности; наличие хотя бы одной функции, которая ссылается на сущность, и т.п. В основе формальной проверки лежат такие прагматичные соображения, как: зачем создавать сущность, если она никогда не используется или если к ней никогда не будет произведен доступ; зачем создавать сущность, которую нельзя однозначно идентифицировать и т.п.
Следует иметь в виду, что большинство современных CASE-средств, используемых при анализе предметной области и проектировании баз данных, содержат ряд возможностей по автоматизации описанных формальных процедур.
Формальные процедуры проверки качества моделей позволяют проектировщику базы данных убедиться в их "формальной" достоверности, но не позволяют оценить, насколько они адекватно отражают реальную ситуацию внешнего мира в рамках предметной области. Поэтому часто требуется прибегать к неформальным процедурам проверки результатов моделирования предметной области.
Неформальные процедуры заключаются в проведении личных бесед с аналитиками, постановщиками задач, конечными пользователями и руководителями всех автоматизируемых подразделений, проведении семинаров и совещаний всех участников проекта, а также в изучении материалов анализа предметной области.В ходе неформальных процедур могут быть выявлены существенные ошибки (например, потеря сущности предметной области), которые могут привести к пересмотру некоторых результатов проектирования и реализации баз данных, что в конечном счете может стать причиной срыва запланированных сроков выполнения проекта.1)
По окончании проверки качества моделей предметной области составляется список замечаний.
Все вопросы, возникшие в ходе проведения контроля качества результатов анализа предметной области, разрешаются проектировщиками совместно с аналитиками и руководителем ИТ-проекта. Результаты проверки доводятся до сведения руководителя проекта.
Литература: [1], [8], [9], [17], [22], [24], [25], [26], [27], [28], [30], [32], [33], [35], [44], [45], [46]
Как видно из таблицы, не существует единой модели, в рамках которой можно представить весь жизненный цикл системы. Так, стадия анализа предметной области системы представляется с помощью трех типов моделей:
Несмотря на то, что каждая из диаграмм может быть представлена с помощью широкого спектра нотаций, все они в рамках определенной диаграммы имеют общие основные черты. Ниже приведены правила, которыми должен руководствоваться проектировщик в ходе формальной проверки правильности представленных моделей.
На диаграммах "сущность-связь" должны быть представлены сущности, связи, степени связи, классы принадлежности сущности, неопределенные связи, супертипы/подтипы сущности. При этом каждая сущность и отношение должны быть поименованы и занесены в словарь данных; каждая сущность может появиться на диаграмме только один раз; каждая сущность должна вступать в отношение (отсутствие "висящих" сущностей), и каждое отношение должно иметь сущности (отсутствие "висящих" отношений). Поэтому проектировщик базы данных должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые, вероятнее всего, будут определять уникальный ключ связи.
Проектировщик базы данных должен проконтролировать, чтобы в информационной модели предметной области для каждого атрибута сущностей был определен домен. Следует понимать, что определение домена, даваемое аналитиками, носит самый общий характер (число, текст, дата, графика и т.д.), и будет далее уточнено при проектировании. На этом этапе важно, чтобы домен был определен.
На диаграммах модели бизнес-процессов должны быть представлены работы, вход, выход, управление и механизмы. При этом все элементы должны быть поименованы; все работы должны получаться путем функциональной декомпозиции некоторой более крупной работы; для каждой работы должно быть задано управление.
На диаграммах потока данных должны быть представлены внешние сущности (источники и потребители данных), процессы обработки данных, конкурирующие процессы, хранилища данных, потоки данных, указатели ветвления процессов. При этом все процессы должны быть пронумерованы: исходный (начальный) процесс должен иметь номер 0; процессы более низких уровней - 1.1, 1.2, и т.д.; 1.1.1, 1.1.2, и т.д.
На диаграммах жизненного цикла сущностей и диаграммах состояний должны быть представлены состояния, переходы и внешние переходы. При этом на диаграммах должно присутствовать начальное состояние, из которого получаются все остальные состояния. В конечное состояние можно попасть из любого состояния. Запрещается одновременно переход в два состояния; каждый переход имеет условие и действие, которые указываются рядом с переходом.
Таким образом, формальные процедуры проверки нацелены на проверку таких аспектов анализа, как: наличие у каждой сущности уникального идентификатора; наличие функции, создающей экземпляры сущности; наличие хотя бы одной функции, которая ссылается на сущность, и т.п. В основе формальной проверки лежат такие прагматичные соображения, как: зачем создавать сущность, если она никогда не используется или если к ней никогда не будет произведен доступ; зачем создавать сущность, которую нельзя однозначно идентифицировать и т.п.
Следует иметь в виду, что большинство современных CASE-средств, используемых при анализе предметной области и проектировании баз данных, содержат ряд возможностей по автоматизации описанных формальных процедур.
Формальные процедуры проверки качества моделей позволяют проектировщику базы данных убедиться в их "формальной" достоверности, но не позволяют оценить, насколько они адекватно отражают реальную ситуацию внешнего мира в рамках предметной области. Поэтому часто требуется прибегать к неформальным процедурам проверки результатов моделирования предметной области.
Неформальные процедуры заключаются в проведении личных бесед с аналитиками, постановщиками задач, конечными пользователями и руководителями всех автоматизируемых подразделений, проведении семинаров и совещаний всех участников проекта, а также в изучении материалов анализа предметной области.
В ходе неформальных процедур могут быть выявлены существенные ошибки (например, потеря сущности предметной области), которые могут привести к пересмотру некоторых результатов проектирования и реализации баз данных, что в конечном счете может стать причиной срыва запланированных сроков выполнения проекта.1)
По окончании проверки качества моделей предметной области составляется список замечаний.
Все вопросы, возникшие в ходе проведения контроля качества результатов анализа предметной области, разрешаются проектировщиками совместно с аналитиками и руководителем ИТ-проекта. Результаты проверки доводятся до сведения руководителя проекта.
Литература: [1], [8], [9], [17], [22], [24], [25], [26], [27], [28], [30], [32], [33], [35], [44], [45], [46]
 |
|
|
Согласно данным исследовательской организации Gartner Group, почти половина проектов реализации ИС с базами данными по тем или иным причинам оказывается неуспешной.
| © 2003-2007 INTUIT.ru. Все права защищены. |
Модель потока данных
Модель потока данных предназначена для описания процессов перемещения данных в предметной области базы данных. Модель потока данных представляется в виде диаграммы потока данных (Data Flow Diagram). Основными элементами диаграммы являются:Источники данных показывают, кто использует или работает c данными. Процессы обработки данных показывают операции, производимые над данными. Хранилища данных показывают места хранения данных. Потоки данных показывают способ передачи данных между источниками и хранилищами данных. Для представления диаграмм потока данных обычно используются сетевые структуры, допускающие повторение сущностей; циклы не используются. Поток изображается слева направо. На диаграммах помечаются допустимые и недопустимые пути перемещения данных, но не показываются процессы управления потоком.
На рис. 2.12 приведен упрощенный вариант диаграммы потока данных для обработки заказа. Квадраты обозначают источники данных, окружности - процессы обработки данных, две параллельные черты - хранилище данных. Линии со стрелками показывают способ передачи данных из одной области в другую. Процессы можно подвергать функциональной декомпозиции, порождая тем самым иерархию диаграмм потока данных.
Рис. 2.12. Простая диаграмма потока данных для обработки заказа
На этом рисунке сущность Клиент (Client) продублирована: клиент делает заказ и получает его. На диаграмме показано два хранилища данных, два процесса и потоки данных между клиентом, процессами и хранилищами данных.
Диаграмма потока данных позволяет:
Диаграмма потока данных предоставляет проектировщику баз данных информацию:
Модель жизненного цикла сущности
Модель жизненного цикла (ЖЦ) сущности предназначена для описания изменения состояний сущности и переходов между ними.Модель ЖЦ сущности представляется в виде диаграммы ЖЦ сущности (Entity Lifecycle Diagram), на которой изображаются пути перехода сущности из некоторого начального состояния в конечное состояние и события, инициирующие изменения состояния сущности. Модель ЖЦ сущности может быть также представлена в виде текстового описания.
Для проектировщика баз данных особенно важны диаграммы ЖЦ тех сущностей, которые многократно меняют свое состояние. Обычно такая сущность имеет атрибут Status (Состояние), характеризующий состояние сущности в текущий момент времени; домен этого атрибута является некоторым множеством значений, задаваемым перечислением. Проектировщику баз данных на стадии создания физической модели базы данных потребуется знание диаграмм ЖЦ сущностей для того, чтобы прописать ограничения на реализацию атрибута Status (Состояние) в базе данных.
На рис. 2.13 приведен пример диаграммы жизненного цикла сущности Чек.
Рис. 2.13. Диаграмма жизненного цикла Чек
Набор спецификаций функций системы
Одной из задач проектирования базы данных является отображение функций системы, содержащихся в требованиях и бизнес-правилах, в набор спецификаций модулей приложений базы данных. При этом проектирование модулей осуществляется параллельно и в согласовании с проектированием базы данных. Поэтому важным дополнением к моделям процессов и состояний, необходимым для проектирования базы данных, является информация о функциональности системы.Аналитики должны предоставить проектировщикам баз данных набор спецификаций функций системы, которые описывают функциональность системы в форме бизнес-категорий - четко сформулированных требований к системе, сгруппированных по направлениям деятельности организации. Иногда предоставляется список зависимостей между функциями и вызывающими их событиями.
Помимо информации об иерархии функций, содержащейся в бизнес-модели процессов области, проектировщику базы данных необходимо иметь текстовое описание каждой из функций системы. При этом оно должно содержать выделенные сущности, применяемые в каждой функции, и используемые атрибуты сущностей, а также однозначно интерпретироваться при прочтении.
Получив набор спецификаций и описание функций системы через атрибуты и сущности, проектировщик базы данных может приступать к разработке спецификаций модулей приложений базы данных.
Бизнес-правила представляют собой конкретные требования и условия для функций, задающие поведение данных. В практике проектирования бизнес-правила используются для поддержки целостности данных в базе данных.
Общесистемные требования и решения
Общесистемные требования и решения о реализуемости базы данных, как правило, формируются менеджером ИТ-проекта на основе анализа данных предметной области. Среди них наиболее важными для проектировщиков базы данных являются следующие требования и решения.Большинство перечисленных требований идут транзитом на следующие этапы процесса проектирования. Проектировщику базы данных на стадии планирования проектирования базы данных необходимо убедиться, что эти требования присутствуют в исходной документации, и в случае, если какие-либо требования отсутствуют, запросить их.
Рассмотрим некоторые примеры возможного неверного принятия решения по выбору СУБД. Предположим, что принято решение о разработке некоторой базы данных на СУБД Oracle. Закуплено и установлено оборудование. Однако информация об объеме базы данных и его потенциальном росте на этапе анализа требований к базе данных отсутствовала. База данных спроектирована и создана, готовится план тестирования приложений базы данных. При составлении плана тестирования базы данных выясняется, что в базе данных будет размещено 1000 записей длиной 100 байт, а рост числа записей базы данных оценивается как 10 записей в год! Базой данных будут пользоваться 4 раза в год для получения 5 видов отчетов. На производство всех отчетов за период требуется один день. Таким образом, цикл простоя системы будет много больше, чем время ее активной работы. В этом случае ответ на вопрос "А зачем выбрана промышленная СУБД Oracle?" имеет вполне экономический смысл.
Имеет место и обратная ситуация. Выбрали СУБД SQLBase. А через два года эксплуатации вышли на объем базы данных в 10 млн записей - цифра, характерная для финансовых подсистем крупного предприятия. И база данных "захлебнулась"!
Проектировщики баз данных! Будьте внимательны! Требуйте предоставления полного набора необходимой для принятия проектных решений информации!
Отношения, связи
Сущности не существуют отдельно друг от друга. Между ними имеются реальные отношения (Relationship), и они должны быть отражены в информационной модели предметной области. При выделении отношений акцент делается на фиксацию связей и их характеристик. Отношение (связь) представляет собой соединение (взаимоотношение) между двумя или более сущностями. Каждая связь реализуется через значения атрибутов сущностей. Обычно связь обозначается глаголом. Каждая связь также должна иметь свой уникальный идентификатор связи.Внимание! В реляционной базе данных отношения реализуются только через ограничение целостности по внешнему ключу. Поэтому проектировщик базы данных должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые будут определять уникальный ключ связи. Выбор ключей сущностей - одно из важнейших проектных решений, которое предстоит сделать проектировщику при переходе от информационной модели предметной области к логической модели базы данных.
Связи характеризуются степенью связи и классом принадлежности сущности к связи. Степень (мощность) связи - это отношение числа сущностей, участвующих в образовании связи. Например, "один-к-одному", "один-ко-многим", "многие-ко-многим". На уровне информационной модели допускается неопределенная или неразрешенная связь. Класс принадлежности сущности - это характер участия сущности в связи. Различают обязательные и необязательные классы принадлежности сущности к связи. Обязательным является такой класс принадлежности, когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности. Для необязательного класса принадлежности сущности степень связи может быть равна нулю, т.е. экземпляр сущности можно связать с 0, 1 или несколькими экземплярами другой сущности. Для обязательного класса принадлежности степень связи не может равняться нулю.
Отношения, связывающие сущность саму с собой, называются рефлексивными. Типичным примером рефлексивных отношений является определение структуры подчиненности в отношении "Сотрудники". Рефлексивные отношения чаще всего отражают иерархические отношения внутри структуры данных. Они порождают ряд проблем проектирования, о которых речь пойдет позже.
С точки зрения отношений различают слабые (weak) сущности. Слабые сущности - это сущности, которые не могут присутствовать в базе данных, пока не существует связанного с ней экземпляра другой сущности. Примером такой сущности является заказ, который не может существовать без клиента. Слабые сущности имеют обязательный класс принадлежности, и степень связи такой сущности не может равняться нулю. Связь "заказ-клиент" является обязательной.
Выявление слабых сущностей и связанных с ними обязательных отношений необходимо для обеспечения целостности и согласованности данных. Так, например, неизвестному клиенту невозможно приписать заказ.
Подтипы и супертипы
Иногда выделенная сущность несет в себе отношение включения или часть-целое. При этом существует некоторый атрибут, значения которого порождают разбиение множества экземпляров сущности на непересекающиеся подмножества - категории сущности. Категории сущности называются подтипами и выделяют в подчиненную в рамках отношения сущность, которая является категорией исходной сущности.Иногда из исходной сущности выделяются общие для полученных категорий атрибуты, и таким образом выделяется сущность, которая становится супертипом. За выделенной сущностью-супертипом обычно оставляют наименование исходной сущности, хотя ее семантический смысл меняется.
Супертип с порожденными им подтипами является примером так называемой составной сущности. Составная сущность является логической конструкцией модели для представления набора сущностей и связей между ними как единого целого.
Пример. Сущность Автомобиль можно разбить на следующие подтипы: автомобили с приводом на два колеса, автомобили с приводом на четыре колеса, автомобили с переключаемым приводом.
Для проектировщика базы данных важно знать, что все экземпляры сущности-супертипа относятся только к одному из ее подтипов. Наличие в модели подтипов и супертипов усложняют проектирование и создают определенные трудности в реализации.
Поэтому важно на ранней стадии проектирования установить, является ли наличие супертипов в модели необходимым. Для этого можно предпринять следующие действия:
Понятие функциональной модели предметной области базы данных
Вторым ключевым моментом создания ИС с целью автоматизации информационных процессов организации является анализ функционального взаимодействия объектов автоматизации. Результаты такого анализа многогранны. Аналитики представляют их в виде функциональной модели предметной области базы данных. Функциональная модель предметной области является собирательным понятием. Состав функциональной модели существенно зависит от контекста конкретного ИТ-проекта и может быть представлен посредством довольно широкого спектра документов в виде текстовой и графической информации. К рассмотрению таких документов проектировщик баз данных должен подходить с учетом следующих двух положений:Описать процессы обработки информации всесторонне с помощью одной описательной модели сложно. В последнее время предпринимаются некоторые успешные попытки разработать унифицированную модель в рамках объектно-ориентированного анализа и проектирования (OOA&D) с помощью UML-конструкций. В настоящих лекциях мы основываемся только на результатах структурного анализа предметной области как наиболее прагматичном подходе для проектирования классических реляционных баз данных. Использование объектно-ориентированного подхода к проектированию баз данных - это предмет отдельного курса лекций.
Определим функциональную модель предметной области базы данных как совокупность некоторых моделей, предназначенных для описания процессов обработки информации. Будем называть эти модели конструкциями функциональной модели. Ниже приведен перечень основных конструкций функциональной модели, необходимые для выполнения проектирования реляционных баз данных.
Понятие предметной области
Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Вопросно-ответные отношения, получая интерпретацию во внешнем мире (мире вне информационной системы), позволяют выделить для информационной системы определенный его фрагмент - предметную область, - который будет воплощен в автоматизированной информационной системе. Информация о внешнем мире представляется в информационной системе (ИС) в форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС. Совокупность этих выделенных для ИС данных, связей между ними и операций над ними образует информационную и функциональную модели предметной области, описывающие ее состояние с определенной точностью.Важно понимать, что информационная и функциональная модели предметной области создаются на этапе анализа требований к базе данных и не содержат предположений о технологии реализации базы данных. Они строятся независимо от выбираемой модели данных (сетевой, иерархической, реляционной, объектно-ориентированной, многомерной и т.д.), поддерживаемой СУБД, модели вычислений, программно-аппаратной платформы для базы данных. Информационная и функциональная модели предметной области являются входными данными для процесса проектирования базы данных. Поэтому проектировщик должен уметь правильно интерпретировать их в ходе решения своих проектных задач.
Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение в рассмотрение понятия предметной области базы данных ограничивает и делает обозримым пространство информационного поиска в ИС и позволяет выполнять запросы за конечное время.
Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, - образует объектное ядро предметной области, которое имеет онтологический статус. Нельзя получить в ИС ответ на вопрос о том, что ей неизвестно. Термин объект является первичным, неопределяемым понятием. Синонимами термина "объект" являются "реалия, сущность, вещь". Однако термин сущность понимается нами несколько уже, как компонент модели предметной области, т.е. как уже выделенный на концептуальном уровне объект для базы данных. Таким образом, выделяемые в предметной области объекты превращаются аналитиками (а не проектировщиками базы данных) в сущности. Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации набора его свойств. Сущность является результатом абстрагирования реального объекта, т.е. в нашем контексте имеет гносеологический статус. Хотя далее в контексте сущность н ередко отождествляется с объектом.
На рис. 2.1 представлен один из подходов к классификации объектов предметной области.
Рис. 2.1. Классификации объектов предметной области
Примерами сущностей (с точки зрения ИС) или объектов (с точки зрения внешнего мира) являются отдельный студент, группа студентов, аудитория, время занятий, слова, числа, символы. Обычно считается, что быть объектом - это значит быть дискретным и различимым. Примеры "не-объектов" - это мир, время, смысл, хотя и такие категории могут сохраняться в базе данных.
С объектами связано две проблемы: идентификация и адекватное описание. Для идентификации используют имя. При этом предполагается, что происходит отказ от его смысла, который присущ естественному языку. Используется только указательная функция имени. Имя - это прямой способ идентификации объекта. К косвенным способам идентификации объекта относят определение объекта через его свойства (характеристики или признаки).
Объекты взаимодействуют между собой через свои свойства, что порождает ситуации.
Ситуации - это взаимосвязи, выражающие взаимоотношения между объектами. Ситуации в предметной области описываются посредством высказываний о предметной области с использованием исчисления высказываний и исчисления предикатов, т.е. формальной, математической логики. Например, высказывание "Программист и менеджер есть служащие компании" описывает отношение включения. Таким образом, вся информация об объектах и сущностях предметной области описывается с помощью утверждений на естественном языке.
Методы математической логики позволяют формализовать эти утверждения и представить их в виде, пригодном для анализа.
Пример. Рассмотрим высказывание: Студент Иванов А.А, родился в 1982 году. Оно выражает следующие свойства объекта "Иванов А.А.":
Первое свойство устанавливает связь между объектами "Иванов А.А." и "Год рождения", а второе - между объектами "Иванов А.А." и "Множество студентов". Формализация этого высказывания представляется как результат присваивания значений переменным, входящим в предикаты:
РОДИЛСЯ (Иванов А.А., 1982)
ЯВЛЯЕТСЯ СТУДЕНТОМ (Иванов А.А.)
Отметим, что в семантике естественных языков ситуация и взаимосвязь считаются почти синонимами. Ситуация содержит высказывание об объектах предметной области, которому можно приписать некоторую оценку истинности и представить в виде предиката после введения переменных. Таким образом, совокупность высказываний о предметной области можно трактовать как определение информационного пространства для базы данных.
На рис. 2.2 представлен один из подходов к классификации ситуаций в рамках предметной области.
Рис. 2.2. Классификация ситуаций предметной области
Различают статические и динамические ситуации. Примерами статических ситуаций являются такие ситуации, как иметь цвет, иметь возраст. Примерами динамических ситуаций являются такие ситуации, как создать утюг, выпечь хлеб.
Обратите внимание на то, что ситуация также может представлять собой объект (см. рис. 2.1) и обладать свойствами. С другой стороны, приведенная классификация рассматривает свойства как специальный случай ситуаций. Подобная коллизия порождает неоднозначность при моделировании предметной области базы данных. Поставим вопрос - что есть цвет автомобиля? Объект, свойство, ситуация? К обсуждению этого вопроса мы вернемся специально в следующей лекции.
Приведенная классификация вводит в предметную область два важных аспекта - пространство и время, причем время и как момент, и как интервал. Предметная область существует в пространстве и во времени, т.е. ей присущи, как и реальному миру, временные и пространственные отношения и связи. Следует отличать реальное время внешнего мира и его отражение в базе данных и в источниках информации. В базе данных взаимосвязи, зависящие от времени, фиксируются только после их регистрации в базе данных. Таким образом, предметная область в каждый конкретный момент времени представляет собой выделенную совокупность определенных объектов и ситуаций, называемую состоянием предметной области (или снимком).
Введем определение предметной области.
Определение. Предметная область - это целенаправленная первичная трансформация картины внешнего мира в некоторую умозрительную картину, определенная часть которой фиксируется в ИС в качестве алгоритмической модели фрагмента действительности.
Понятие предметной области было введено в начале 80-х годов прошлого века, когда учеными в области ИС была осознана необходимость использовать семантические модели для представления информации в компьютерных системах. Так же как требования к компьютерной системе формируются средствами естественного языка, так и информация в компьютерных системах представляется средствами особого языка с определенной семантикой. Такой подход впервые был представлен П. Ченом в 1976 году.
Сущности, атрибуты и идентификаторы (ключи) сущности, домены атрибутов
Предметом информационной модели является абстрагирование объектов или явлений реального мира в рамках предметной области, в результате которого выявляются сущности (entity) предметной области. Как правило, они обозначаются именем существительным естественного языка.Сущность описывается с помощью данных, именуемых свойствами или атрибутами (attributes) сущности. Как правило, атрибуты являются определениями в высказывании о сущности и обозначаются именами существительными естественного языка. Сущности вступают в связи друг с другом через свои атрибуты. Каждая группа атрибутов, описывающих одно реальное проявление сущности, представляет собой экземпляр (instance) сущности. Иными словами, экземпляры сущности - это реализации сущности, отличающиеся друг от друга и допускающие однозначную идентификацию.
Внимание! При представлении сущности в базе данных хранятся только ее атрибуты.
Одним из основных компьютерных способов распознавания сущностей в базе данных является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, то для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.
Некоторые сущности имеют естественные идентификаторы. Например, естественным идентификатором счета-фактуры является его номер. Идентификаторы сущности могут быть составными - составленными из нескольких атрибутов и атомарными - составленными из одного атрибута сущности.
Идентификация сущностей проводится аналитиками. Однако чаще всего их решение не является окончательным! Задача проектировщика баз данных - обеспечить при сохранении экземпляров сущности в базе данных наличие у каждого ее нового экземпляра уникального идентификатора. Уникальный идентификатор сущности - это атрибут сущности, позволяющий отличать одну сущность от другой. Если сущность имеет несколько уникальных идентификаторов, так называемых возможных ключей, то проектировщик должен выбрать первичный ключ сущности.
Различают однозначные и многозначные атрибуты. Однозначными являются атрибуты, которые в пределах конкретного экземпляра сущности имеют только одно значение. В противном случае они считаются многозначными.
Важным моментом изучения информационной модели проектировщиком является выделение многозначных атрибутов сущности. Это связано с тем, что реляционная модель базы данных не поддерживает многозначных атрибутов, и они должны быть разрешены на последующих стадиях проектирования.
Каждый атрибут сущности имеет домен (domain). Домен - это выражение, определяющее значения, разрешенные для данного атрибута. Иными словами, домен - это область значений атрибута. Проектировщик базы данных должен проконтролировать, чтобы в информационной модели предметной области для каждого атрибута сущностей был определен домен.
На уровне информационного моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или "не определен". В последнем случае аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в логической и физической моделях базы данных уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели базы данных домен реализуется посредством механизма ограничения домена, СУБД не понимает неопределенных доменов.
Основы проектирования реляционных баз данных
Бизнес-модель этапа проектирования - создание физической модели реляционной базы данных
В данном разделе рассмотрим организационную сторону решения профессиональной задачи проектировщика баз данных - задачу создания физической модели реляционной базы данных. Основная цель решения этой задачи: преобразовать логическую модель реляционной базы данных в последовательность команд SQL для создания объектов реляционной базы данных. Таким образом, проектировщик базы данных отображает отношения логической модели реляционной базы данных (сущности предметной области, представленные в нормализованной форме на ER-диаграммах) в таблицы и индексы реляционной базы данных.Эта задача включает выполнение ряда обязательных последовательных процедур.
В данном разделе рассмотрим организационную сторону решения профессиональной задачи проектировщика баз данных - задачу создания физической модели реляционной базы данных. Основная цель решения этой задачи: преобразовать логическую модель реляционной базы данных в последовательность команд SQL для создания объектов реляционной базы данных. Таким образом, проектировщик базы данных отображает отношения логической модели реляционной базы данных (сущности предметной области, представленные в нормализованной форме на ER-диаграммах) в таблицы и индексы реляционной базы данных.
Эта задача включает выполнение ряда обязательных последовательных процедур.
Бизнес-модель этапа проектирования
Решая профессиональную задачу создания физической модели данных - учет влияния транзакций, - проектировщик базы данных стремиться создать такую физическую модель данных, которая, по его мнению, давала бы наибольшую производительность обработки запросов базы данных. На практике, особенно при создании и разработке новых баз данных, такая задача вряд ли может быть решена полностью. Ясно, что для ее решения необходимо иметь список всех запросов к базе данных, их частоте и объеме выборок по каждому, что в принципе невозможно. Поэтому проектировщики базы данных на основе анализа исходной документации и опросов потенциальных пользователей пытаются систематизировать транзакции к базе данных, оценить кардинальность таблиц в целом и отдельных колонок в частности. На основе таких оценок проектировщик базы данных пытается определить критические транзакции и настроить структуры таблиц, задействованных в таких транзакциях, на достижение, с его точки зрения, максимальной производительности. При этом он выдвигает гипотезы о применимости того или иного способа повышения производительности обработки запросов и умозрительно проверяет их. Далее он принимает решение о применении наиболее подходящего, с его точки зрения, способа увеличения производительности запросов.Следует понимать, что задача обеспечения высокой производительности базы данных - это задача, которую постоянно решает администратор базы данных в процессе ее эксплуатации. На этом этапе проектирования базы данных проектировщик, по мере возможности, готовит успешное решение этой задачи. Эта этап является очень ответственным в физическом проектировании базы данных, поэтому следует соблюдать при решении этой задачи разумный прагматизм и документировать свои решения. Должно действовать эмпирическое правило: если проектировщик базы данных не имеет достаточно данных для надежного решения задачи повышения производительности базы данных, то решение этой задачи должно быть передано администратору базы данных.
На этом этапе проектирования физической модели реляционной базы данных проектировщик базы данных:
В результате проектировщик базы данных создает физическую модель базы данных, которая учитывает характер обработки данных в базе данных, выраженный через учет влияния транзакций.
Перейдем теперь к построению бизнес-модели этапа проектирования физической модели реляционной базы данных: учет влияния транзакций. Из сказанного в предыдущих разделах настоящей лекции понятен следующий алгоритм действий:
Определение основного типа приложения базы данных Документирование и описание транзакций Определение критических транзакций Для каждой критической транзакции: Определение таблиц транзакции Определение способа повышения производительности Денормализация таблицы? Разбиение таблицы? Секционирование таблицы? Кластеризация таблицы? Построение дополнительных индексов? Изменение структуры внутренней схемы базы данных Документирование изменений Для каждой таблицы базы данных Выбор индексов Определение транзакций таблицы Определение кардинальности таблиц Определение кардинальности колонок Определение индексов Изменение внутренней схемы
На рис. 3.9 ниже представлена модель бизнес- процессов стадии проектирования физической модели базы данных с учетом влияния транзакций. На рис. рис. 3.10 - декомпозиция работы по индексированию базовой таблицы.
Рис. 3.9. Декомпозиция этапа проектирования - создание первой итерации физической модели базы данных: внутренняя схема
Рис. 3.10. Декомпозиция работы по индексированию базовой таблицы
Следует еще раз отметить субъективный характер принятия решений проектировщиком базы данных из-за отсутствия во многих случаях точных сведений о характере выполнения транзакций в системе. Большинство решений принимается на основе эвристических правил и личного опыта проектировщика. Метод работы проектировщика базы данных сводится к изменению структуры объектов базы данных на основе перебора возможных способов повышения производительности, их сопоставления и обоснованного выбора подходящего решения.
На этом мы заканчиваем рассмотрение задач проектировщика базы данных по созданию физической модели реляционной базы данных с учетом влияния транзакций. Главная цель этого этапа - видоизменить последовательность команд SQL для создания объектов хранения данных с учетом влияния транзакций на производительность базы данных.
Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных
Перейдем ко второму уровню функциональной декомпозиции процесса проектирования базы данных в рамках его первого этапа - сбор и анализ входных данных. На рис. 3.3 представлена диаграмма декомпозиции процесса проектирования базы данных второго уровня, отражающая основные задачи этапа сбора и анализа входных данных.
Рис. 3.3. Диаграмма декомпозициии процесса проектирования базы данных: второй уровень. Сбор и анализ входных данных
Такими задачами являются:
В ходе контроля качества основными моментами деятельности являются контроль ER-диаграмм и контроль диаграмм функциональной модели предметной области. На основании ER-диаграмм создается логическая модель реляционной базы данных; на основании диаграмм функциональной модели разрабатывается серверный код и проектируются модули приложений базы данных.
Систематизация требований заказчика к базе данных проводится с целью их адекватного распределения по этапам проектирования базы данных. Важным результатом систематизации является вывод о достаточности требований и реализуемости базы данных. Заказчик должен точно знать, что он получит и чего не получит в результате создания базы данных! Особенно важно указать, чего он не получит. Анализ требований на реализуемость базы данных в рамках конкретного ИТ-проекта служит основой для принятия решения менеджером проекта о возможности реализации проекта в целом.
Создав бизнес-модель проектирования базы данных, вы, фактически, составили план проектирования базы данных. Позициями рабочего плана являются работы бизнес-модели процесса проектирования базы данных, которые дополняются сведениями об ответственных исполнителях и сроках исполнения. Каждый уровень декомпозиции процесса уточняет этот план.
Настоящая бизнес-модель процесса проектирования базы данных представляет собой достаточно простой типичный пример бизнес-модели проектирования. В общем случае содержание бизнес-модели проектирования зависит от многих факторов: личности менеджера и состава команды проекта, объема проекта, проектных рисков и т.д.
В конце каждого модуля курса мы будем рассматривать диаграмму декомпозиции следующего этапа проектирования базы данных. Таким образом, к концу изучения курса у вас будет построена достаточно полная бизнес-модель процесса проектирования реляционной базы данных.
Бизнес-модель процесса проектирования
Продолжим функциональную декомпозицию процесса проектирования реляционной базы данных в рамках его второго этапа - создания логической модели базы данных.Основной целью этапа создания логической модели базы данных является преобразование информационной модели предметной области базы данных в логическую модель реляционной базы данных. Создание логической модели базы данных предполагает решение следующих основных задач и выполнения операций в рамках таких задач:
Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных. Отметим, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в информационной модели предметной области, например связывающая сущность при нормализации отношения со степенью связи "многие-ко-многим". Иногда на этом этапе принимается решение о выборочной денормализации отношений.
На рис. 3.4-рис. 3.6 представлены бизнес-модели процессов создания логической модели базы данных, нормализации сущности предметной области и нормализации отношений логической модели базы данных соответственно.
Рис. 3.4. Бизнес-модель процесса создания логической модели базы данных
Рис. 3.5. Бизнес-модель процесса нормализации сущности
Рис. 3.6. Бизнес-модель процесса нормализации отношения
Представленные задачи составляют минимально необходимый набор задач, позволяющих спроектировать логическую модель базы данных, и могут рассматриваться как один из возможных способов организации работ в этой области.
Что такое проектирование базы данных
Значительная часть проектов в области информационных технологий (далее ИТ-проектов) направлена на разработку и создание информационных систем, в рамках которых осуществляется обработка данных различной сложности. Целью таких проектов является разработка и создание информационной системы с базами данных. Практически во всех таких проектах решается задача проектирования баз данных определенного типа. Решение задачи проектирования повышает вероятность того, что разрабатываемая информационная система (далее - система) будет удовлетворять заданным функциональным и информационным требованиям с учетом заданных ограничений.Примеры функциональных требований: выдача отчетов по продажам по регионам; выдача отчетов по продажам по кварталам; автоматический расчет скидок на товары при увеличении объема закупаемой партии и т.п.
Примеры ограничений: максимальное время, отпущенное на проект; количество денежных средств, которое можно на него потратить. Следует также учитывать технологические средства, доступные при реализации проекта, например требование реализации базы данных в архитектуре "файл-сервер".
В эксплуатации база данных и ее окружение должны удовлетворять набору требований по ряду укрупненных (интегрированных) параметров, таких как:
Это далеко не полный перечень параметров, по которым выставляются требования к базам данных, однако он содержит параметры, требования по которым выставляются наиболее часто.
Такие параметры иногда находятся в противоречии друг к другу. Так, высокие требования по функциональности на данном конкретном оборудовании могут вступать в конфликт с высокими требованиями по производительности. Например, отчеты могут генерироваться в течение нескольких часов и снизить в это время реакции пользователей, работающих с системой в диалоговом режиме.
Параметры, выражающие требования к базе данных, могут ранжироваться посредством присвоения приоритетов.
Присвоение высшего приоритета требованию создать структуру данных для достижения системой максимально возможной производительности может привести к тому, что при проектировании базы данных требование обеспечить удобство работы определенной категории пользователей будет рассматриваться через призму производительности. Например, в системе бронирования авиабилетов в транснациональной авиакомпании время отклика на запрос не должно превышать 15-30 секунд. Поэтому, если это требование не будет удовлетворяться, то потребуется "разгрузить" приложение оператора.
Таким образом, процесс проектирования базы данных заключается в достижении компромиссов между функциональными, информационными, аппаратными, архитектурными и технологическими требованиями к базе данных и строится на информированном принятии решений по структуре базы данных.
Введем определение проектирования баз данных.
Определение 1. Проектирование базы данных - это поиск способов удовлетворения функциональных требований средствами имеющейся компьютерной технологии с учетом заданных ограничений.
Как правило, ИТ-проекты по созданию базы данных включают в себя следующие этапы: определение стратегии построения системы, анализ требований к базе данных, проектирование базы данных, реализация базы, тестирование и внедрение базы данных. Этап проектирования базы данных считается одним из самых сложных "размытых" этапов создания базы данных, который не имеет явно выраженного начала и окончания. По сравнению с анализом требований к базе данных или разработкой приложений, проектирование базы данных, по мнению многих ведущих специалистов, является плохо структурированной задачей. Если все этапы создания базы данных перекрываются друг с другом в своей последовательности, то этап проектирования перекрывается со всеми остальными этапами. Проектирование начинается с момента принятия стратегических решений и продолжается на этапах реализации и тестирования.
Процесс проектирования базы данных охватывает несколько основных сфер.
Отметим, что приложения работы с базой данных проектируются одновременно с физической схемой базы данных, а не отдельно! Зачастую вычислительная среда задается в качестве входных условий проектирования, но иногда проектирование следует проводить с учетом возможного перехода в будущем на другую аппаратную платформу или технологию.
Внимание! Базы данных всегда проектируются под конкретное назначение системы.
Техника проектирования баз данных может измениться в целом и в деталях в зависимости от назначения системы. Например, следует различать проектирование систем складирования данных и проектирование так называемых OLTP-систем, ориентируемых на оперативную обработку транзакций. В данном учебном курсе рассматривается проектирование баз данных в основном для OLTP-систем. Именно на таких системах исторически сложилась техника проектирования баз данных.
Известно, что база данных:
Таким образом, база данных является сложным многокомпонентным объектом, объединяющим аппаратное обеспечение, программное обеспечение, информацию в виде данных и персонал.Основной задачей проектировщика базы данных является обоснованный выбор такой ее структуры, которая обеспечит согласованное взаимодействие всех ее компонентов согласно заданным функциональным требованиям в рамках заданных ограничений.
В данном курсе мы не рассматриваем вопросы анализа предметной области. Эта задача предшествует проектированию базы данных, и решают ее аналитики. Однако проектировщик баз данных должен знать результаты выполнения этой задачи и уметь правильно интерпретировать их в ходе проектирования. Результаты анализа предметной области базы данных, а именно модели данных предметной области на семантическом уровне, являются исходными данными для решения задач проектирования базы данных. Поэтому проектировщик должен знать концепции, лежащие в основе моделирования данных предметной области, и конструкции, образующие совокупность этих моделей.
Краткое рассмотрение задач создания серверного кода и подготовки скрипта
Профессиональная задача проектирования баз данных - разработка серверного кода базы данных - возникает, как правило, в многопользовательской вычислительной среде.В многопользовательских системах пользователи совместно используют вычислительные ресурсы, в частности ресурсы дисковой памяти и оперативной памяти процессора. Вычислительные ресурсы могут быть сконцентрированы в одном месте (централизованные вычисления) или быть рассредоточенными в различных узлах, объединенных в компьютерную сеть (распределенные вычисления). СУБД в любом случае призвана координировать и осуществлять доступ пользователей к базам данных и их объектам.
Большинство современных СУБД поддерживают концепцию клиент-серверной технологии для распределенных вычислений. Это означает, что существуют концентраторы вычислений (называемые серверами), на которых выполняется наибольший объем вычислений с данными (серверы баз данных), и машины пользователей (клиенты), на которых выполняются приложения пользователей.
Приложения формируют запросы в форме команд SQL к базам данных, отправляют их серверам баз данных, получают запрашиваемые данные и обрабатывают их.
В клиент-серверной вычислительной среде приложение может взаимодействовать с сервером баз данных по другой схеме: когда приложение отправляет запрос, этот запрос обрабатывается на сервере, а приложению возвращается готовый результат.
Работа приложения по второй схеме основывается на использовании так называемого серверного кода (server-side code) - любого кода, выполняемого компьютером, на котором установлена СУБД. Ядро СУБД выполняет этот код в базе данных и возвращает приложению только результат. Например, это может быть несколько колонок строки или вычисленное значение.
Использование серверного кода может значительно сократить объем сетевого трафика и тем самым увеличить производительность базы данных в целом. Однако СУБД должна иметь встроенные средства для распознавания и обработки такого кода. Многие фирмы - производители промышленных СУБД, в том числе и Oracle, предлагают процедурные расширения SQL, с помощью которых можно выполнять построчную обработку данных, использовать циклы, сложные вычисления и операции управления данными.
PL/ SQL является таким расширением SQL в СУБД Oracle 9i. Он позволяет создавать серверный код в виде объектов реляционной базы данных, таких, как хранимые процедуры, функции, пакеты и триггеры. Проектировщик реляционной базы данных, который использует для создания базы данных СУБД Oracle, имеет возможность рассмотреть создания таких объектов с целью сокращения сетевого трафика или принять решение о переносе определенного объема обработки на сервер, особенно в тех случаях, когда эта обработка выполняется очень интенсивно. Например, несколько строк разных таблиц проверяются перед вставкой новой строки.
Таким образом, разработка серверного кода сводится к решению следующих подзадач:
Задача проектирования базы данных - подготовка инсталляционного скрипта для создания базы данных - в определенной степени завершающая для самостоятельной работы проектировщика базы данных. Такой скрипт - это один из главных результатов его работы.
Проектировщик базы данных, выполнив предыдущие задачи, фактически выполнил свою основную работу над созданием скрипта для базы данных. Если работа по проектированию базы данных закончена, зачем проектировщику еще что-то делать, кроме того как проанализировать и проверить проделанную работу, отредактировать окончательный вариант скрипта и создать физическую базу данных? Принято считать, что задача создания базы данных, так же как и управление базой данных, является задачей администратора базы данных. Значит, можно задокументировать проделанную работу и передать ее администратору базы данных.
Однако процесс проектирования физической модели базы данных не закончен. Из нашего рассмотрения выпали следующие вопросы:
Типовая бизнес-модель процесса проектирования базы данных
Процесс проектирования базы данных может быть представлен в виде модели бизнес-процессов. Обычно проектировщики не создают бизнес-модель процесса проектирования базы данных. А напрасно! Бизнес-модель процесса проектирования позволяет:Рассмотрим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.
Рис. 3.1. Контекстная диаграмма процесса проектирования базы данных
Как видно из рисунка, на вход процесса проектирования базы данных подаются:
Могут быть представлены и другие документы.
Примечание. Под задачами обратного влияния здесь понимается совокупность проблем, которые возникают в процессе разработки приложений базы данных, ее тестирования, опытной и промышленной эксплуатации и приводят к модификации физической модели базы данных. Примером такой задачи является настройка операторов SELECT с целью увеличения производительности выборки.
На выходе процесса проектирования базы данных формируются следующие результаты:
По требованию может быть разработана и другая документация.
Продолжим функциональную декомпозицию процесса проектирования базы данных. На рис. 3.2 приведена диаграмма декомпозиции процесса проектирования базы данных первого уровня, отражающая основные наиболее крупные профессиональные задачи (этапы) проектирования базы данных.
Внимание! В настоящем курсе рассматривается минимально необходимый, с точки зрения автора, набор задач, позволяющий спроектировать реляционную базу данных.
Рис. 3.2. Диаграмма декомпозиция процесса проектирования базы данных: первый уровень
Такими задачами (этапами) являются:
Сбор и анализ входных данных - это начальный этап проектирования, на котором осуществляется сбор и контроль качества результатов анализа предметной области базы данных, готовится план проектирования базы данных.
Создание логической модели базы данных - это этап, на котором на основании информационной модели предметной области базы данных создается логическая структура базы данных, независимая от ее реализации.
Создание физической модели базы данных: внутренняя схема - это этап, на котором на основании логической модели базы данных создается физическая структура базы данных, зависимая от ее реализации. На этом этапе выполняется преобразование отношений логической модели реляционной базы данных в команды создания объектов физической базы данных, в результате чего создается так называемая внутренняя схема базы данных. Дополнительно может быть создана так называемая внешняя схема базы данных, которая отражает точку зрения пользователей на данные в базе данных. Полученный скрипт может быть применен для создания физической базы данных.
Создание физической модели базы данных: учет влияния транзакций - это этап, на котором анализируются возможные транзакции системы, выполняется, в случае необходимости, денормализация отношений для обеспечения более высокой производительности базы данных.
Продолжим функциональную декомпозицию процесса проектирования базы данных. На рис. 3.2 приведена диаграмма декомпозиции процесса проектирования базы данных первого уровня, отражающая основные наиболее крупные профессиональные задачи (этапы) проектирования базы данных.
Внимание! В настоящем курсе рассматривается минимально необходимый, с точки зрения автора, набор задач, позволяющий спроектировать реляционную базу данных.
Рис. 3.2. Диаграмма декомпозиция процесса проектирования базы данных: первый уровень
Такими задачами (этапами) являются:
Сбор и анализ входных данных - это начальный этап проектирования, на котором осуществляется сбор и контроль качества результатов анализа предметной области базы данных, готовится план проектирования базы данных.
Создание логической модели базы данных - это этап, на котором на основании информационной модели предметной области базы данных создается логическая структура базы данных, независимая от ее реализации.
Создание физической модели базы данных: внутренняя схема - это этап, на котором на основании логической модели базы данных создается физическая структура базы данных, зависимая от ее реализации. На этом этапе выполняется преобразование отношений логической модели реляционной базы данных в команды создания объектов физической базы данных, в результате чего создается так называемая внутренняя схема базы данных. Дополнительно может быть создана так называемая внешняя схема базы данных, которая отражает точку зрения пользователей на данные в базе данных. Полученный скрипт может быть применен для создания физической базы данных.
Создание физической модели базы данных: учет влияния транзакций - это этап, на котором анализируются возможные транзакции системы, выполняется, в случае необходимости, денормализация отношений для обеспечения более высокой производительности базы данных.
Основы проектирования реляционных баз данных
Декартово произведение отношений
Операция декартова произведения выполняется над двумя произвольными отношениями А и В. Результатом операции декартова произведения является отношение С, степень которого равна сумме степеней исходных отношений, а мощность - произведению мощностей исходных отношений. Таким образом, декартово произведение отношений можно представить с помощью декартова произведения множеств:
Пример. Операция "декартово произведение". Выполним операцию декартова произведения отношений СЛУЖАЩИЕ и МЕДОСМОТР.
Исходные отношения: СЛУЖАЩИЕ (#, Фамилия, Пол) МЕДОСМОТР (Процедура, Дата)
| 1 | Иванов | М | ЭКГ | 17.08 | |
| 5 | Антонова | Ж | Анализ крови | 20.08 | |
| Терапевт | 23.08 |
Результирующее отношение:
РЕЗУЛЬТАТЫ_МЕДОСМОТРА ( #, Фамилия, Пол, Процедура, Дата ) =
СЛУЖАЩИЙ Х МЕДОСМОТР
| 1 | Иванов | м | ЭКГ | 17.08 |
| 1 | Иванов | м | Анализ крови | 20.08 |
| 1 | Иванов | м | Терапевт | 23.08 |
| 5 | Антонова | ж | ЭКГ | 17.08 |
| 5 | Антонова | ж | Анализ крови | 20.08 |
| 5 | Антонова | ж | Терапевт | 23.08 |
Деление отношений
Операция деления выполняется над двумя отношениями А и В, где А - отношение-делимое, а B - отношение-делитель. При этом атрибуты B должны являться подмножеством атрибутов A. Результатом выполнения операции деления является отношение С, которое включает в себя атрибуты отношения А, отличные от атрибутов отношения В, и только те кортежи, декартовы произведения которых с отношением В дают отношение А:
Представление частного отношений через другие алгебраические операции может быть получено следующим образом. Предположим, что
. Пусть n и m - арности отношений Qa и Qb, n > m. Тогда разность исходных отношений есть множество кортежей t степени n - m, таких, что для всех кортежей s степени m из Qb, кортеж ts принадлежит Qa. Пусть 
. Тогда 
есть множество кортежей степени n, не принадлежащих Qa. Каждый из них формируется из n - m первых компонентов кортежа из Qa, за которым следуют компоненты кортежа Qb. Пусть далее 
есть множество кортежей t степени n - m, состоящих из первых n - m компонентов Qa, причем для каждого из них в Qb существует некоторый кортеж s степени m, такой, что ts не принадлежит Qa. Таким образом, разность отношений T - V есть, по определению, частное отношений 
.Пример. Деление отношений. Выполним операцию деления отношения РЕЗУЛЬТАТЫ_МЕДОСМОТРА на отношение МЕДОСМОТР.
Исходные отношения:
РЕЗУЛЬТАТЫ_МЕДОСМОТРА (#, Фамилия, Пол, Процедура, Дата)
МЕДОСМОТР (Процедура, Дата )
| 1 | Иванов | М | ЭКГ | 17.08 |
| 1 | Иванов | М | Анализ крови | 20.08 |
| 1 | Иванов | М | Терапевт | 23.08 |
| 5 | Антонова | Ж | ЭКГ | 17.08 |
| 5 | Антонова | Ж | Анализ крови | 20.08 |
| 5 | Антонова | Ж | Терапевт | 23.08 |
Результирующее отношение:
| ЭКГ | 17.08 |
| Анализ крови | 20.08 |
| Терапевт | 23.08 |
СЛУЖАЩИЙ (#, Фамилия, Пол) = РЕЗУЛЬТАТЫ_МЕДОСМОТРА / МЕДОСМОТР
| 1 | Иванов | М |
| 5 | Антонова | Ж |
Формы представления отношений
Как мы уже упоминали выше, отношения можно представлять в виде таблиц. Но в табличном представлении сложно показывать некоторые свойства отношений. Например, неоднозначность трактовки домена колонки. Поэтому предпринимаются попытки строить более четкие схемы описания отношений в реляционных базах данных. Ниже представлен фрагмент такого описания в виде примера схемы базы данных "КАДРЫ":СХЕМА "ОТДЕЛ_КАДРОВ"
ДОМЕН Т_Табельный_номер ТИП целое ДОМЕН Т_ФИО ТИП символьное ДОМЕН Т_Зарплата ТИП десятичное с фиксированной точкой ..... ОТНОШЕНИЕ Служащий ( Табельный-номер / КЛЮЧ / ДОМЕН = Т_Табельный-номер, ФИО / ДОМЕН = Т_ФИО, .... ) .... КОНЕЦ ОПИСАНИЯ СХЕМЫ.
Подобное описание не прижилось среди проектировщиков баз данных. На практике прибегают к такому описанию крайне редко.
Для дальнейшего изложения нам понадобится одно из самых важных понятий обработки данных - понятие ключа.
Ключом или ключевым полем называется уникальное значение, которое позволяет тем или иным способом идентифицировать сущность или часть сущности предметной области, т.е. ключ - это значение некоторого атрибута или атрибутов в кортеже отношения, который представляет экземпляр сущности в реляционной модели данных.
Внимание! На данном этапе изложения мы не проводим особого различия между понятиями "ключ отношения" и "ключ сущности" предметной области, хотя далее мы будем эти ключи различать.
Заметим, что в определении ключа не требуется однозначной идентификации сущности предметной области базы данных. Ключ отношения - это не уникальный идентификатор сущности предметной области. Однако последний есть возможный кандидат на ключ отношения, иначе говорят, возможный ключ.
Принято различать первичные ключи и частичные ключи. Математически первичным ключом отношения R со схемой r является подмножество сужения декартового произведения, которое позволяет однозначно идентифицировать кортеж. Если первичный ключ содержит несколько атрибутов, то он называется составным ключом, в противном случае - атомарным.
Частичным ключом называется атрибут составного ключа, если он однозначно определяет совокупность неключевых атрибутов отношения. Атрибут кортежа, который является первичным ключом другого отношения, называется внешним (иногда посторонним) ключом.
Из определения отношения следует следующее важное свойство реляционной модели данных: каждое отношение должно иметь первичный ключ. Отсутствие первичного ключа в отношении может привести к приобретению кортежей, которые не определены текущим состоянием предметной области, или к потере уже существующих кортежей при выполнении теоретико-множественных операций. Причина подобных казусов лежит в механизме построения декартова произведения.
Заметим, что ключ в контексте модели предметной области базы данных всегда отражает ту или иную степень связи между атрибутами сущностей предметной области, т.е. семантически ключ есть средство моделирования связей в модели.
Пример: рассмотрим предложение "Гражданин Иванов проживал в городе Москве 10 лет". Возможными атрибутами в отношении Место_жительства являются фамилия гражданина, название города проживания и время проживания. Фамилия гражданина может выступать в качестве первичного ключа этого отношения, так как личность однозначно определяет время ее проживания в конкретном городе. Таким образом, в этом отношении моделируется связь "проживал" между атрибутами "фамилия" и "город".
Отношения в реляционной модели данных, как правило, представляются с помощью функциональной формы записи (так как мы записывает функции нескольких переменных в математическом анализе), при этом атрибуты первичного ключа подчеркиваются:
ИМЯ_ОТНОШЕНИЯ (Атрибуты первичного ключа, неключевые атрибуты).
Пример. Представление связи отношением. Представим связь между личностью и местом ее проживания через отношение ПРОЖИВАЕТ (Кл. личность, Кл. населенный_пункт, время)
Описание личности:
ЛИЧНОСТЬ (Кл. личность, ФИО, возраст, пол)
Описание населенного пункта:
НАСЕЛЕННЫЙ_ПУНКТ (Кл.населенный_пункт, география, население)
Однако наибольшее распространение получило представление отношений в виде графических диаграмм, например ER-диаграмм, о которых мы говорили в первой лекции. Преимуществами такого представления являются наглядность диаграмм и возможность их построения в ряде CASE-средств проектирования баз данных. Обычно CASE-средства позволяют поддерживать несколько уровней представления отношений. Так, например, ErWin поддерживает уровень логической и физической моделей базы данных.
Отметим, что представление фрагментов реального мира через отношения даже в рамках одной модели данных не характеризуется единственностью. Например, зададимся вопросом: "Что есть цвет автомобиля? Связь, объект или атрибут?" Если за объект принять автомобиль, то цвет может выступать в качестве атрибута автомобиля. Если рассматривать зависимость отражательной способности покрытия автомобиля от его цвета, то цвет можно считать объектом. Если рассматривать взаимосвязь между цветом модели автомобиля и ее номером, то цвет можно считать связью.
В любом случае при представлении какого-либо качества реального мира в модели следует четко понимать, какие запросы в рамках создаваемой модели данных должны быть разрешимыми. Рассмотрим отношение КРАСНЫЙ (модель). При использовании такого отношения на вопрос: "Является ли модель X красного цвета?" может быть получен ответ: "Да" или "Нет". Вопрос: "Какой цвет у модели Х?" ответа не имеет, так как в отношении отсутствует атрибут "цвет".
В итоге сформулируем основные свойства реляционной модели данных, которые следуют из понятия отношения как множества.
Объединение отношений
Пусть Qa, Qb, Qc - множество кортежей отношений А, B, С соответственно. Операция объединения выполняется над двумя совместными отношениями A и B. Результатом операции объединения является отношение C, которое включает в себя все кортежи отношения А и кортежи отношения B, отличные от кортежей отношения A. Таким образом, объединение отношений можно представить с помощью теоретико-множественной операции объединения:
Пример. Объединение отношений. Выполним операцию объединения отношений КЛИЕНТ_1 и КЛИЕНТ_2.
Исходные отношения:
КЛИЕНТ_1 (#, Фамилия, Возраст) и КЛИЕНТ_2 (#, Фамилия, Возраст)
| 1 | Иванов | 20 | 1 | Иванов | 20 | |
| 3 | Петров | 23 | 2 | Исаев | 30 | |
| 4 | Фролов | 49 |
Результирующее отношение:
КЛИЕНТ (#, Фамилия, Возраст) = КЛИЕНТ_1 " КЛИЕНТ_2
| 1 | Иванов | 20 |
| 3 | Петров | 23 |
| 4 | Фролов | 49 |
| 2 | Исаев | 30 |
Пересечение отношений
Операция пересечения выполняется над двумя совместными отношениями А и В. Результатом операции пересечения является отношение С, которое включает в себя кортежи отношения А, полностью совпадающие с кортежами отношения В. Таким образом, пересечение отношений можно представить с помощью теоретико-множественной операции пересечения:
Пример. Пересечение отношений. Выполним операцию пересечения отношений КЛИЕНТ_1 и КЛИЕНТ_2.
Исходные отношения:
КЛИЕНТ_1 (#, Фамилия, Возраст) и КЛИЕНТ_2 (#, Фамилия, Возраст)
| 1 | Иванов | 20 | 1 | Иванов | 20 | |
| 3 | Петров | 23 | 2 | Исаев | 30 | |
| 4 | Фролов | 49 |
Результирующее отношение:
КЛИЕНТ (#, Фамилия, Возраст) = КЛИЕНТ_1 " КЛИЕНТ_2
| 1 | Иванов | 20 |
Понятие отношения
Реляционная модель данных была предложена Е.Ф. Коддом в 1970 году и получила к настоящему времени широкое распространение и популярность. Этому способствовали два ее существенных достоинства: 1) однородность представления данных в модели, которая обусловливает простоту восприятия ее конструкций пользователями базы данных, и 2) наличие развитой математической теории реляционных баз данных, которая обусловливает корректность ее применения.В основе реляционной модели данных лежит понятие отношения, которое задается списком своих элементов и перечислением их значений. Рассмотрим пример на рис. 4.1. На нем представлено расписание движения автобусов по маршруту "Москва - Черноголовка - Москва". Налицо определенная структура. Каждый включенный в расписание рейс имеет свой номер, время отправления и время в пути. Расписание может быть представлено таблицей. Заголовки колонок таблицы носят название атрибутов. Список их имен носит названия схемы отношения. Каждый атрибут определяет тип представляемых им данных, который вместе с областью его значений называется доменом. Вся таблица целиком называется отношением, а каждая строка таблицы носит название кортежа отношения. Таким образом, отношение можно представить в виде двумерной таблицы.
Рис. 4.1. Расписание движения автобусов по маршруту "Москва - Черноголовка - Москва" как отношение
Подходы к определению понятия отношения могут быть различными. Математически отношение может быть определено как множество кортежей, являющейся подмножеством декартова произведения фиксированного числа областей (доменов). В результате получаем, что в каждом кортеже должно быть одинаковое число компонент (атрибутов) и значение каждого из них выбирается из некоторого определенного домена.
Введем ряд математических определений, связанных с понятием отношения.
Определение 1. Декартово произведение Пусть D1, D2, ..., Dn - произвольные конечные множества, не обязательно различные. Декартовым произведением этих множеств
называется множество вида 
.
Пример:
Определение 2. Схема отношения
Пусть
- имена атрибутов. Схемой r отношения R называется конечное множество имен атрибутов 
.Определение 3. Отношение
Отношением со схемой r на конeчных множествах D1, D2,…, Dn называется подмножество R декартового произведения
.Элементы отношения (d1, d2, ..., dn), как уже упоминалось выше, называются кортежами. О каждом отношении, являющимся подмножеством декартового произведения
, можно сказать, что оно имеет арность n. Кортеж (d1, d2, ..., dn) имеет n компонентов. Для обозначения кортежа применяется и сокращенная форма записи d1, d2, ..., dn. Использование понятия декартового произведения для определения отношения в реляционной модели данных делает модель конструктивной. На математическом языке это означает, что все остальные понятия модели определяются в рамках строго математического построения на базе декартового произведения.Табличная форма представления отношения была введена в целях популяризации модели среди неподготовленных пользователей баз данных. Трактовка реляционной теории на уровне таблиц скрывает ряд определений, важных для понимания как теории реляционных баз данных, так и языка манипулирования данными, моментов.
Во-первых, атрибуты разных отношений могут быть определены на одном домене, так же как и атрибуты одного отношения. Это очень важное обстоятельство, позволяющее устанавливать связи по значению между отношениями. Во-вторых, множество математически по своему определению не может иметь совпадающих элементов, и, следовательно, кортежи в отношении можно различить лишь по значению их компонент. Это тоже очень важное для модели обстоятельство: никакие два кортежа не могут иметь полностью совпадающих компонент. Таким образом, в реляционной модели полностью исключается дублирование данных о сущностях реального мира! В-третьих, заметим, что схема отношения также есть множество, что позволяет работать с ними с помощью теоретико-множественных операций. Это является важным моментом для построения теории проектирования реляционных схем баз данных.
Существует определенное различие между математическим определением отношения и действительным хранением отношений в памяти компьютера. По определению, отношение не может иметь два идентичных кортежа. Однако СУБД, поддерживающие реляционную модель данных, хранят отношения в файлах операционной системы компьютера. Размещение отношений в файлах операционной системы допускает хранение идентичных кортежей. Если не используется специальная техника (контроль целостности по первичному ключу), то обычно большинство промышленных СУБД допускают хранение двух идентичных кортежей в базе данных.
С математической точки зрения однородность реляционной модели, о которой упоминалось выше, состоит в том, что схема отношения является постоянной, иначе говоря, каждая строка таблицы имеет один и тот же формат. С другой стороны, предполагается, что каждая строка таблицы представляет некую сущность реального мира или связь между ними. Обладают ли сущности реального мира такой однородной структурой, является вопросом, на который должен ответить аналитик или эксперт-пользователь. Решение о пригодности использования реляционной модели для моделирования данных конкретной предметной области решается руководителем ИТ-проекта и аналитиками.
Проекция отношения
Операция проекции выполняется над одним отношением А. Результатом выполнения операции проекции над отношением А является отношение С, которое включает в себя все кортежи отношения А, но только с теми атрибутами, на которые выполняется проекция. Операцию проекции отношения можно представить следующим образом:
Для обозначения проекции в теории реляционных баз данных принято использовать греческую букву
, а для обозначения атрибутов, которые участвуют в операции проекции, принято использовать их номера или имена как подстрочные индексы . Предполагается, что существует взаимно однозначное соответствие между номерами атрибутов и их именами для данной схемы отношения. Для обозначения атрибутов, которые участвуют в проекции, в формуле выше использованы индексы i1, i2, …, iN, где N - число атрибутов проекции.Таким образом, операция проекции заключается в удалении некоторых атрибутов в исходном отношении Qa и упорядочивании оставшихся атрибутов.
Пример. Проекция отношения. Выполним операцию проекции отношения СОТРУДНИК на атрибуты ОТДЕЛ и ДОЛЖНОСТЬ.
Исходное отношение: СОТРУДНИК (#, Фамилия, Отдел, Должность)
| 1 | Иванов | 12 | Инженер |
| 2 | Исаев | 11 | Гл.специалист |
| 3 | Петров | 11 | Инженер |
| 4 | Фролов | 11 | Инженер |
| 5 | Антонова | 12 | Конструктор |
Результирующее отношение:
ДОЛЖНОСТЬ (Отдел, Должность) = p (Отдел, Должность)
Разность отношений
Операция разности выполняется над двумя совместными отношениями А и В. Результатом операции разности является отношение С, которое включает в себя кортежи отношения А, отличные от кортежей отношения В. Таким образом, разность отношений можно представить с помощью теоретико-множественной операции разности:
Отметим для дальнейшего, что пересечение отношений можно представить через разность отношений как Qa - (Qa - Qb).
Пример. Разность отношений. Выполним операцию разности отношений КЛИЕНТ_1 и КЛИЕНТ_2.
Исходные отношения:
КЛИЕНТ_1 (#, Фамилия, Возраст) и КЛИЕНТ_2 (#, Фамилия, Возраст)
| 1 | Иванов | 20 | 1 | Иванов | 20 | |
| 3 | Петров | 23 | 2 | Исаев | 30 | |
| 4 | Фролов | 49 |
Результирующее отношение:
КЛИЕНТ (#, Фамилия, Возраст) = КЛИЕНТ_1 - КЛИЕНТ_2
| 3 | Петров | 23 |
| 4 | Фролов | 49 |
Реляционные операции
Классическая реляционная модель данных предусматривает использование восьми реляционных операций манипулирования данными: объединение, пересечение, разность, декартово произведение, деление, проекция, соединение и выбор. К операциям модели можно также отнести и операцию переименования кортежей в отношении.Рассмотрим каждую из операций. Отметим, что операции выполняются над отношением в целом, а не над отдельным кортежем отношения. Введем несколько вспомогательных определений.
Определение 4. Степень отношения есть число входящих в него атрибутов или мощность схемы отношения (как множества).
Определение 5. Мощность отношения есть число входящих кортежей или кардинальное число отношения (как множества).
Определение 6. Два отношения называются совместными, если они имеют совместные схемы (совпадают схемы отношений и домены соответствующих атрибутов).
Соединение отношений
Операция q-соединения выполняется над двумя отношениями А и В. Результатом выполнения операции
-соединения является отношение С, которое включает в себя все кортежи со всеми атрибутами исходных отношений А и В, удовлетворяющими заданному условию. В каждом отношении выделяется атрибут, по которому выполняется соединение.Операция соединения отношений может быть представлена следующим образом:
где n - степень отношения Q_a;
- арифметический оператор сравнения; i, j - номера атрибутов в Q_a и Q_b соответственно, по которым выполняется соединение.Рассмотрим частные случаи
-соединения.Если
есть арифметический оператор равенства, то такое соединение называется эквисоединением. При этом имена атрибутов исходных отношений могут не совпадать.Различают еще естественное соединение, когда оба отношения имеют набор одинаковых по именам и типам атрибутов. Соединение выполняется по всему набору совпадающих атрибутов. Пусть R1 (A1, A2,..., An, B1, ...) и R2 (A1, A2, ..., An, C1, ...) - исходные отношения, тогда естественное соединение может быть вычислено следующим образом для одного атрибута:
;, у которых совпадают значения в колонках R1.А и R2.А, где R1.А - имя колонки в , соответствующее колонке А из R1. Аналогично для R2.А.;
Пример. Соединение отношений. Выполним операцию естественного соединения отношений ЭКЗАМЕН_ВЕДОМОСТЬ и ГРУППА по атрибуту "Группа".
Исходные отношения:
ЭКЗАМЕН_ВЕДОМОСТЬ (Студент, Дисциплина, Оценка, Группа)
| Иванов | Математика | 5 | 12 |
| Петров | Математика | 3 | 10 |
| Исаев | Математика | 4 | 1 |
| Антонова | Математика | 3 | 12 |
ГРУППА (Курс, Группа, Наименование)
| 5 | 10 | АСУ |
| 5 | 11 | Прикладная математика |
Результирующее отношение:
РЕЗУЛЬТАТ (Студент, Дисциплина, Оценка, Группа, Курс, Наименование)
| Петров | Математика | 3 | 10 | 5 | АСУ |
| Исаев | Математика | 4 | 11 | 5 | Прикладная математика |
Литература: [1], [2], [3], [4], [5], [6], [11], [14], [15], [16], [20], [37], [39], [42], [43], [44], [45], [47].
Выбор из отношения
Операция выбора (селекции) выполняется над одним отношением А. Результатом выполнения операции выбора является отношение С, которое включает в себя кортежи отношения А, удовлетворяющие заданному условию (критерию выбора). Операция выбора из отношения может быть представлена следующим образом:
где s обозначает операцию выбора, F - критерий выбора на множестве атрибутов в форме логического выражения, образованного с помощью определенных операндов (константы, имена атрибутов, арифметические операции сравнения, логические операции).
Пример. Селекция отношения. Произведем выбор из отношения СЛУЖАЩИЕ по критерию "Возраст >= 30".
Исходное отношение:
СЛУЖАЩИЕ (#, Фамилия, Возраст)
| 1 | Иванов | 20 |
| 2 | Исаев | 30 |
| 3 | Петров | 23 |
| 4 | Фролов | 49 |
| 5 | Антонова | 25 |
Критерий выбора: Возраст >= 30
Результирующее отношение:
СЛУЖАЩИЕ (#, Фамилия, Возраст)
| 2 | Исаев | 30 |
| 4 | Фролов | 49 |
Основы проектирования реляционных баз данных
Аксиомы вывода функциональных зависимостей
Известно, что функции могут образовывать пространства, и в пространствах выполняются различные операции. В нашем случае для каждой базы данных на множестве ее отношений можно рассмотреть все возможные, допустимые в семантическом смысле функциональные зависимости. Для каждого отношения существует вполне определенное множество ФЗ между его атрибутами. На практике число рассматриваемых атрибутов и ФЗ конечно (!).Поскольку ФЗ являются высказываниями об атрибутах сущностей предметной области, то над ними могут быть определены операции, позволяющие логически получать одну зависимость из другой (или устанавливать между ними эквивалентность). Это позволяет определить для данной схемы базы данных базовый набор ФЗ, из которого может быть выведено все множество ФЗ, присущих этой схеме. Данное утверждение является третьей (3) конструктивной идеей в теории проектирования реляционных баз данных.
Математически эту задачу можно поставить следующим образом. Пусть U {A1, A2, ..., An} - универсальное множество атрибутов, т.е. полный набор атрибутов отношения базы данных. Совокупность пар (X, Y), таких, что
, задает структуру ФЗ отношения R. Такое отношение называют еще универсальным отношением. Задача состоит в построении такого набора ФЗ, из которого могут быть получены все ФЗ базы данных.Например, транзитивную ФЗ в отношении r можно логически вывести из
и 
. Пусть отношение содержит два кортежа - t и s, совпадающие по атрибуту А, но не совпадающие по С. Нужно выяснить, совпадают ли кортежи t и s по атрибуту В. Если это не так, то нарушается зависимость 
. Если существует совпадение для В, то, поскольку по условию не совпадают компоненты по С, то будет нарушена зависимость 
. Таким образом, отношение удовлетворяет зависимости 
.Такие рассуждения позволяют ввести следующие определения.
Определение 7. Пусть F - множество ФЗ для схемы отношения r,
- некоторая ФЗ. Говорят, что ФЗ логически следует из F, если для каждого отношения R со схемой r, удовлетворяющего ФЗ из F, удовлетворяется также зависимость .В примере выше мы видели, что если F содержит ФЗ из
и , то зависимость логически следует из F.Определение 8. Пусть F - множество ФЗ для схемы отношения r. Тогда замыканием F+ множества ФЗ F называется множество ФЗ, которое логически следует из F. F называется полным семейством ФЗ, если F+ = F.
Пример (без доказательства). Пусть
. Тогда F+ состоит из всех зависимостей , таких, что выполняется одно из следующих условий:
или 
;
или B; есть 
или 
.Теперь можно уточнить понятие ключа отношения. Предполагается, что для сущностей предметной области существует множество атрибутов, которое уникально определяет каждую из этих сущностей. Понятие замыкания позволяет дать формальное определение ключу отношения.
Определение 9. Пусть F - множество ФЗ для схемы отношения R(A1, A2, ..., An). Подмножество атрибутов X называется ключом отношения R, если ФЗ:
принадлежит F+ и не для какого собственного подмножества 
ФЗ: 
не принадлежит F+.Таким образом, заданный аналитиком ключ некоторого набора сущностей предметной области только тогда является ключом отношения, представляющего эти сущности в реляционной базе данных, когда он является минимальным ключом, т.е. содержит минимальное подмножество ключевых атрибутов. При определении ключа сущности предметной обычно невозможно установить свойство минимальности ввиду отсутствия формальной разработки для этой процедуры. На практике существует несколько наборов атрибутов сущности предметной области в качестве кандидатов на ключ отношения. Проектировщик базы данных может выбрать любой из них для идентификации отношения. Для того чтобы выделять ситуацию множественности в выборе ключа, для обозначения ключа сущности пользуйтесь термином возможный ключ.
Пример. Многозначность при выборе ключа
Легко убедиться, что оба множества атрибутов {город, адрес} и {адрес, почтовый_индекс} являются ключами отношения. Какой из них выбрать, решает проектировщик базы данных.
Для того чтобы определить ключи отношений и логические следствия ФЗ для заданной схемы отношения, необходимо вычислить F+ или для заданного F уметь определять, принадлежит ли данная ФЗ его замыканию F+. Для этого необходимо иметь набор правил - операций над ФЗ, позволяющих ими манипулировать.
Набор правил вывода должен быть полным, т.е. давать возможность вывести все зависимости из F+, и надежным, т.е. не позволять вывести зависимость из F, не принадлежащую F+. Таким образом, правила вывода, называемые также аксиомами вывода функциональных зависимостей, должны позволять вывести множество функциональных зависимостей, присущих рассматриваемой схеме отношения R(A1, A2, ..., Am) на заданном универсальном множестве атрибутов U по заданному множеству ФЗ F = {F1, F2, ..., Fk}.
Далее представлены восемь аксиом вывода функциональных зависимостей.
, то ФЗ следует из F. Иначе 
.
и задана ФЗ из F, то имеет место ФЗ 
. и задана ФЗ 
из F , то имеет место ФЗ 
.
и задана ФЗ , то 
имеет место ФЗ 
.
, и задана ФЗ , то 
имеет место ФЗ 
., и заданы ФЗ и ФЗ 
, то имеет место ФЗ 
.
, и заданы ФЗ и ФЗ , то имеет место ФЗ 
.
, и задана ФЗ , то имеет мето ФЗ . Используя три первых аксиомы вывода, покажем, что пара атрибутов {адрес, почтовый_индекс} из примера выше являются ключом отношения (город, адрес, почтовый_индекс), иначе имеет место ФЗ адрес, почтовый_индекс
город, адрес, почтовый_индекс. Задана ФЗ: почтовый_индекс город. Используя аксиому пополнения, пополним эту ФЗ атрибутом адрес, получаем адрес, почтовый_индекс город, адрес. Задана ФЗ город, адрес почтовый_индекс. Используя аксиому пополнения, пополнив эту ФЗ атрибутами город, адрес, получим город, адрес город, адрес, почтовый_индекс.
Тогда по аксиоме транзитивности получаем адрес, почтовый_индекс
город, адрес, почтовый_индекс.Можно доказать утверждение о том, что настоящие правила вывода позволяют по заданному множеству ФЗ F построить все зависимости, допускаемые на U. Таким образом, система правил вывода ФЗ 1-6 является надежной и полной.
Покажем, как можно доказать утверждение о полноте и надежности аксиом вывода. Аксиомы 1, 2 и 3 составляют независимое подмножество среди всех шести аксиом и называются аксиомами Армстронга. Из них можно вывести все остальные аксиомы. Поэтому надежность и полноту достаточно установить только для первых трех аксиом.
Надежность аксиом заключается в том, что если ФЗ
выведена из F с помощью этих аксиом, то она справедлива на любом отношении, на котором справедливы ФЗ из F. Аксиома рефлексивности является надежной, так как нельзя иметь отношение R с двумя кортежами, которые совпадают по Х, но не совпадают по некоторому его подмножеству. Для доказательства аксиомы пополнения предположим, что имеется отношение R и справедлива ФЗ на R. Однако есть два кортежа t и s, которые совпадают по атрибутам XZ, но не совпадают по YZ. Поскольку они не могут совпадать по какому-либо атрибуту из Z, то они не должны совпадать по некоторому атрибуту из Y. Тогда они совпадают по X, но не совпадают по Y, что противоречит существованию ФЗ . Надежность аксиомы транзитивности уже была доказана в настоящем учебном элементе ранее.Для доказательства полноты аксиом вывода введем понятие замыкания множества атрибутов X относительно множества ФЗ F.
Определение 10. Пусть F - множество ФЗ на множестве атрибутов U и
. Тогда замыканием X+ множества ФЗ F называется множество атрибутов А, таких, что ФЗ 
может быть выведена из F по аксиомам 1-3.Нетрудно показать, что ФЗ
следует из аксиом 1-3 тогда и только тогда, когда 
. По определению замыкания для каждого атрибута из Y выводится ФЗ 
. По аксиоме объединения имеет место ФЗ . Обратно, если выполняется ФЗ , то по аксиоме декомпозиции имеет место ФЗ 
каждый атрибут из Y, и, следовательно, имеет место .Теперь, для того чтобы показать полноту аксиом 1-3, покажем, что если при заданном F ФЗ
не может быть выведена из данных аксиом, то должно существовать такое отношение, в котором справедливы все ФЗ F, кроме ФЗ .Рассмотрим отношение R с двумя кортежами:
| 1 1 … 1 | 1 1 … 1 |
| 1 1 … 1 | 0 0 … 0 |
не удовлетворяется на R. Допустим обратное. Из 
следует 
, иначе два кортежа, совпадая по Х, не совпадают по Y. Тогда ФЗ следует из аксиом 1-3, что приводит к противоречию. Таким образом, аксиомы 1-3 полны.На основе аксиом вывода можно уточнить понятие замыкания множества ФЗ
, как наименьшего множества, содержащего F, которое не может быть расширено за F с помощью аксиом 1, 2 и 3. Понятие замыкания является основным при доказательстве приведенного выше утверждения. Оно также важно при определении, имеет ли множество ФЗ F зависимость . Для этого достаточно проверить, принадлежит ли рассматриваемая зависимость множеству F+.Вычисление замыкания конечного множества ФЗ является трудоемкой задачей, так как необходимо перебрать множество всех подмножеств, а таких множеств, как известно, 2n, где n - число элементов исходного множества. Однако вычислить замыкание X+ для данного множества атрибутов несложно. Алгоритм вычисления приведен ниже. Можно показать, что этот алгоритм корректно вычисляет замыкание X+.
Алгоритм вычисления X+
Input: U - конечное множество атрибутов, множество ФЗ F на U, множество
.Output: X+
. Условие завершения. Так как U - конечно и
, то существует i, такое, что Xi = Xi+1.Пример. Вычислим Х+
Пусть
. 
. Присоединим E и G к X0. X1 = BDEG. Находим ФЗ с левыми частями из 
. Находим ФЗ с левыми частями из 
.
.Минимальные покрытия множеств функциональных зависимостей
Попытаемся теперь выяснить, какова роль F-зависимостей в реляционных базах данных. Как показали исследования, класс F-зависимостей оказывает существенное влияние на построение согласованных схем реляционных баз данных, определяет механизмы согласованности данных и целостности баз данных.Одной из основных целей создания базы данных является сохранение всех данных и взаимосвязей между ними из предметной области в вычислительной среде. Табличное представление отношений в реляционных базах данных позволяет выдвинуть следующую гипотезу хранения данных - каждой ФЗ по отношению. Другой целью создания базы данных является надежность и целостность сохраняемых данных. Можно предположить, что табличное представление породит ряд проблем, связанных с восстанавливаемостью данных, и вступит в противоречие с требованием производительности базы данных. Поэтому меньшее число F-зависимостей означает меньший объем использования памяти компьютера и меньшее число проверок при операциях модификации.
В начале проектирования реляционных баз данных всегда возникает задача представления множеств F-зависимостей. Чем меньшим числом отношений их можно представить, тем лучше. Формализация решения этой задачи строится на понятии покрытия ФЗ. Построение покрытий множеств ФЗ является четвертой (4) конструктивной идеей в теории проектирования реляционных баз данных. Введем ряд определений.
Определение 11. Два множества F-зависимостей F и G над схемой r отношения R эквивалентны, если их замыкания совпадают, т.е. F+ = G+.
Эквивалентность двух множеств ФЗ F и G устанавливается следующим образом: для каждой ФЗ
из F проверяется ее принадлежность G+; для этого вычисляется Y+; затем проверяется вложение Z в Y+; если каждая зависимость F принадлежит G+, то каждая зависимость в F+ принадлежит G+; далее повторяем процедуру для G по отношению к F.Следствием введения понятия эквивалентности является следующий важный факт: каждое множество ФЗ покрывается некоторым множеством ФЗ, в которых ни одна из правых частей не имеет более одного атрибута (правила декомпозиции и объединения).
Таким образом, существует набор эквивалентных схем для каждой исходной схемы отношений реляционной базы данных.
Теория проектирования реляционных баз данных дает возможность построения более коротких представлений ФЗ. Для рассмотрения таких процедур введем понятия неизбыточных ФЗ и минимального покрытия множеств ФЗ.
Определение 12. Множество F-зависимостей F неизбыточно, если у него нет собственного подмножества, эквивалентного ему самому.
Определение 13. Множество F-зависимостей F минимально, если оно содержит не больше F-зависимостей, чем любое эквивалентное ему множество.
Минимальное покрытие (МП) не может содержать избыточных зависимостей. Понятие МП F можно детализировать следующим образом:
из F множество 
не эквивалентно F; из F и собственного подмножества 
множества 
не эквивалентны.Доказано, что для каждого множества ФЗ F существует эквивалентное ему минимальное покрытие. Для заданного F может существовать несколько минимальных покрытий. Ниже приведены общие алгоритмы проверки избыточности и построения минимальных покрытий.
Алгоритмы проверки избыточности
Алгоритм REDUNDANT ( F ) input: Множество F output: True, если F избыточно 1. temp = false for any X
Y < F do if MEMBER ( F - { X Y } , X Y ) then temp = True Return ( temp )Алгоритм NONREDUN ( G ) input: Множество ФЗ G output: Неизбыточное покрытие G 1. F = G for any X
Y > G do if MEMBER (F - { X Y }, X Y ) then F = F - { X Y } Return (F)Основные классы функциональных зависимостей
Анализ связей между сущностями в предметных областях позволяет выделить различные классы функциональных зависимостей.Для определения ФЗ предметной области часто бывает недостаточно определить все возможные ключи отношения. Значения атрибутов могут зависеть от ключа по-разному. Различают классы полных и частичных ФЗ. ФЗ может быть частичной, когда значение неключевого атрибута зависит от значений некоторых атрибутов составного ключа, и полной, когда значения неключевого атрибута зависят от значений всех атрибутов составного ключа.
Введем определение.
Определение 3. Говорят, что неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа. Если неключевой атрибут зависит от части составного ключа, то говорят о частичной ФЗ.
Пример. Частичные и полные ФЗ
ПРЕПОДАВАТЕЛЬ_ПРЕДМЕТ (Личный номер, Предмет, Фамилия, Должность, Оклад, Часы)
| 1. | Иванов | доцент | 25000 | Математика | 40 |
| 2. | Исаев | доцент | 25000 | Физика | 50 |
| 3. | Фролов | профессор | 50000 | Химия | 30 |
Первичным ключом отношения ПРЕПОДАВАТЕЛЬ_ПРЕДМЕТ является пара атрибутов Личный_номер-Предмет. Значения атрибута Количество_часов зависят от значения атрибута Предмет, т.е. имеем частичную ФЗ Предмет
Часы. Значения атрибута Фамилия зависят от значений атрибутов Личный_номер-Предмет, т.е. имеем полную функциональную зависимость {Личный_номер, Предмет} Фамилия.Рассмотрим проблему избыточности данных с точки зрения существования определенных функциональных зависимостей. Избыточность данных может проявляться в виде дублирования значений некоторых атрибутов. Так, например, если несколько преподавателей находятся на одной и той же должности, то их оклады могут совпадать. Атрибут Оклад частично зависит от ключа отношения, но однозначно определяется атрибутом Должность. Разделение исходного отношения на два новых отношения позволит исключить дублирование данных.
Таким образом, выявление определенных функциональных зависимостей в отношениях базы данных позволяет преобразовать их с целью исключения избыточности и повышения надежности данных.
Разбиение исходных отношений в соответствии с функциональными зависимостями - это вторая (2) конструктивная идея в теории проектирования реляционных баз данных. Формирование схем отношений путем разбиения исходных отношений по их атрибутам с учетом функциональных зависимостей является одним из способов создания хороших схем реляционных баз данных.
Каким образом можно использовать это наблюдение с учетом семантики данных для конструирования отношений? Имеет смысл разбить все возможные зависимости на определенные типы ФЗ, и на основе этой классификации проанализировать, какие типы ФЗ к каким аномалиям в выполнении реляционных операций приводят. Такой анализ может стать основой для построения алгоритмов проектирования реляционной базы данных.
Анализ связей между сущностями в предметных областях позволяет определить, наряду с частичной и полной ФЗ, еще несколько классов ФЗ. Одним из таких классов является класс транзитивных ФЗ.
Определение 4. Пусть X, Y, Z - атрибуты отношения R. Если при этом имеются ФЗ
и 
, но отсутствуют ФЗ 
и 
, то говорят, что Z транзитивно зависит от Х. Такие ФЗ называются транзитивными (Т-зависимостями).Пример. Транзитивные ФЗ
Личный номер преподавателя определяет его должность, т.е. имеет место ФЗ Личный_номер
Должность. С другой стороны, согласно тарификации каждой должности назначается определенный оклад, т.е. имеет место ФЗ Должность Оклад. Каждый преподаватель получает за работу соответствующий должности оклад, т.е. оклад преподавателя определяется через его должность.Очевидно, что семантическая связь между атрибутами отношения может носить неоднозначный характер, это порождает существование класса многозначных зависимостей (MV-зависимостей). Например, один преподаватель может преподавать несколько предметов, а один предмет может преподаваться несколькими преподавателями. Многозначная зависимость может быть следующих типов: 1:N (один ко многим), M:1 (многие к одному) и M:N (многие ко многим).
Определение 5. Пусть r - некоторая схема отношения, X и Y - подмножества атрибутов r.
Если при заданных значениях атрибутов из {X} существует некоторое множество, состоящее из нуля или более взаимосвязанных значений атрибутов из {Y}, никак не связанных со значениями других атрибутов этого отношения r - X - Y, то говорят о существовании многозначной зависимости между атрибутами X и Y:
(класс MV-зависимостей).Формально многозначная зависимость означает, что если в отношении
имеются два кортежа t и s, такие, что их значения совпадают по атрибутам из Х, т.е. t[X] = s[X], то данное отношение содержит кортежи w и v, такие, чтоФактически многозначная зависимость означает, что значения атрибутов из Y в кортежах t и s можно поменять местами и получить два новых кортежа, также принадлежащих отношению R.
Разделение установленных функциональных зависимостей по различным отношениям может привести к нарушению принципа замкнутости реляционных операций, потере некоторых существующих кортежей или появлению мнимых кортежей. Это обстоятельство приводит к необходимости выделения еще одного класса функциональных зависимостей - класса зависимостей по соединению (J-зависимостей). Этот класс ФЗ требует от ФЗ наличия свойства восстанавливаемости по своим проекциям с помощью естественного соединения.
Пусть U - универсальное отношение, полученное объединением всех атрибутов сущностей предметной области в одно отношение.
Определение 6. Пусть r = {r_1, …, r_p} - множество схем на U. Отношение R \subset U удовлетворяет зависимости по соединению, если R разлагается без потерь на r как
Процесс выделения новых классов функциональных зависимостей может быть продолжен. Он аналогичен классификации чисел в школьном курсе алгебры: натуральные числа
целые числа рациональные числа действительные числа. В теории реляционных баз данных уже выделены ветвящиеся и циклические функциональные зависимости, предпринимаются попытки расширить набор реляционных операций. Введение новых классов функциональных зависимостей обусловлено следующим важным обстоятельством: при декомпозиции схем реляционных отношений могут быть потеряны как функциональные зависимости, так и кортежи (или приобретены несуществующие кортежи).Каждый класс функциональных зависимостей позволяет проанализировать механизм потери данных или функциональной зависимости и сформулировать правила, которые позволят этого избежать.Однако для практических целей проектирования реляционных баз данных достаточно знания рассмотренных классов ФЗ. Даже зависимость по соединению встречается очень редко.
Понятие функциональной зависимости в данных
Оставим пока в стороне ответ на вопрос, почему проекты реляционных баз данных бывают плохими, т.е. зачем нужно проектировать реляционную базу данных. Попытаемся сначала ответить на вопросы "В чем заключается проектирование реляционных баз данных? и "Что лежит в основе процедур проектирования реляционных баз данных?"Как известно, основной единицей представления данных в реляционной модели является отношение, которое математически задается списком имен атрибутов, иначе - схемой отношения. На стадии логического проектирования реляционной базы данных проектировщик определяет и выстраивает схемы отношений в рамках некоторой предметной области, а именно - представляет сущности, группирует их атрибуты, выявляет основные связи между сущностями. Так, в самом общем смысле проектирование реляционной базы данных заключается в обоснованном выборе конкретных схем отношений из множества различных альтернативных вариантов схем.
На практике построение логической модели базы данных, независимо от используемой модели данных, выполняется с учетом двух основных требований: исключить избыточность и максимально повысить надежность данных. Эти требования вытекают из требования коллективного использования данных группой пользователей. Формальных средств описания данных, необходимых для проверки правильности заполнения конструкций моделей, явно недостаточно. Выбор сущностей, атрибутов и фиксация взаимосвязей между сущностями зависит от семантики предметной области и выполняется системным аналитиком субъективно в соответствии с его личным пониманием специфики прикладной задачи. Разные люди определяют и представляют данные по-разному.
Поэтому любое априорное знание об ограничениях предметной области, накладываемых на взаимосвязи между данными и значения данных, и знания об их свойствах и взаимоотношениях между ними может сыграть определенную роль в соблюдении указанных выше требований. Формализация таких априорных знаний о свойствах данных предметной области базы данных нашла свое отражение в концепции функциональной зависимости данных, т.е.
Такая ФЗ обозначается как
.Как видно из определения, функциональная зависимость инвариантна к изменению состояний базы данных во времени.
Пример. Понятие функциональной зависимости Продемонстрируем понятие функциональной зависимости на примере графика полетов аэропорта. ГРАФИК_ПОЛЕТОВ (Пилот, Рейс, Дата_вылета, Время_вылета)
| Иванов | 100 | 8.07 | 10:20 |
| Иванов | 102 | 9.07 | 13:30 |
| Исаев | 90 | 7.07 | 6:00 |
| Исаев | 100 | 11.07 | 10:20 |
| Исаев | 103 | 10.07 | 19:30 |
| Петров | 100 | 12.07 | 10:20 |
| Петров | 102 | 11.07 | 13:30 |
| Фролов | 90 | 8.07 | 6:00 |
| Фролов | 90 | 12.07 | 6:00 |
| Фролов | 104 | 14.07 | 13:30 |
Следовательно:
"Время_{} вылета"; "Рейс"; "Пилот".Важной задачей при выявлении функциональных зависимостей на атрибутах отношения, которое по определению является множеством, является выяснение, какой из атрибутов выступает как аргумент, а какой - как значение ФЗ. Наиболее подходящими кандидатами в аргументы ФЗ являются возможные ключи, так как кортежи представляют экземпляры сущности, которые идентифицируются значениями атрибутов своего ключа. Нестрого говоря, функциональная зависимость имеет место на отношении, когда значения кортежа на одном множестве атрибутов однозначным образом определяют значения кортежа на другом множестве атрибутов. Это рабочее определение ФЗ не содержит в себе тех формальных элементов, которые позволяют ответить на вопрос "А как проверить наличие ФЗ между атрибутами отношения?" Необходимый для этого формализм дает нам использование реляционных операций.
Для получения формального (строгого) определения н аличия ФЗ в отношении обратимся к реляционным операциям.
Определение 2. Пусть имеется отношение R со схемой r, X и Y - два подмножества R. ФЗ
имеет место на R, если множество 
имеет не более одного кортежа для каждого значения х. Такая ФЗ называется также F-зависимостью.Как видно из определения, формальная проверка наличия ФЗ
в отношении R состоит в выборе (селекции) отношения по значениям возможного ключа и установлении наличия однозначности между его значением и значениями других атрибутов.Алгоритм, который проверяет, удовлетворяет ли отношение R ФЗ
, состоит в сортировке отношения по значениям возможного ключа и установления факта однозначности между его значением и значениями других атрибутов. Этот алгоритм полезен, но он носит вспомогательный характер.Ясно, что если семантика предметной области базы данных сложна, то проверить кортежи на принадлежность к ФЗ достаточно сложно. Сложно вообще установить наличие самой функциональной зависимости, отвечающей природе рассматриваемых данных. С помощью такого формального метода можно выявить ФЗ, которые не являются реальными и носят случайный характер. Проектировщику реляционных баз данных следует знать о таком методе проверки наличия ФЗ, но при проектировании новой базы данных его применение малоэффективно. Он может быть полезен при реинжиниринге существующей базы данных.
Функциональные зависимости фактически представляют собой утверждения обо всех отношениях предметной области. Эти отношения могут являться значениями схемы r и, в сущности, не могут быть получены формальными методами. Единственный способ установления функциональных зависимостей для схемы отношения r - это исследование семантики атрибутов сущностей предметной области. Являясь высказываниями о сущностях предметной области, они не могут быть доказаны. Это обстоятельство по существу порождает неединственность представления предметной области отношениями реляционной БД.
Здесь уместно высказать гипотезу о том, почему бывают хорошие и плохие проекты баз данных.Во-первых, в силу субъективности подходов к анализу предметной области аналитики могут упустить важные ФЗ. Это может привести к тому, что, работая на множестве заведомо неэквивалентных схем, проектировщик создаст неудовлетворительный проект базы данных. Во-вторых, неединственность представления предметной области отношениями приводит к проблеме выбора из множества альтернатив. При этом схема базы данных, выбранная из набора эквивалентных схем, является правильной, но может организовывать данные для пользователя непривычным образом. В-третьих, можно определить ("накроить") схемы баз данных таким образом, что в результате операций с ФЗ будут потеряны и ФЗ, и сами данные.
ограничений на возможные взаимосвязи между данными, которые могут быть текущими значениями схемы отношений.
Кортежи отношений могут представлять экземпляры сущности предметной области или фиксировать их взаимосвязь. Но даже если эти кортежи определены правильно, т.е. отвечают схеме отношения и выбраны из допустимых доменов, не всякий из них может быть текущим значением некоторого отношения. Например, возраст человека редко бывает более 120 лет, или один и тот же пилот не может одновременно выполнять два различных рейса. Такие ограничения семантики домена практически не влияют на выбор той или иной схемы отношений. Они представляют собой ограничения на типы данных.
Априорные ограничения предметной области на взаимосвязь значений отдельных атрибутов оказывают наибольшее влияние на процесс проектирования схем реляционных баз данных. Соответствие по значению определенных атрибутов различных отношений базы данных, т.е. зависимость их значений друг от друга, определяет показатели надежности и корректности сохраняемых данных при их коллективном и согласованном использовании.
Вспомним определение функции как соответствия множества аргументов определенным значениям из множества определения функции и способы задания функций: формула, график и перечисление (таблица). Нетрудно понять, что функциональную зависимость (ФЗ) можно определить на довольно широком классе объектов. Определение функции не накладывает никаких ограничений на множество аргументов и множество значений функции, кроме их существования и наличия соответствия между их элементами. Поскольку ФЗ можно задать таблично, а таблица есть форма представления отношения, то становится очевидной связь между ФЗ и отношением. Отношение может задавать ФЗ. Это утверждение является первой (1) конструктивной идеей, которая положена в основу теории проектирования реляционных баз данных.
Определение 1. Пусть r (A1, A2, ..., An) - схема отношения R, a X и Y - подмножества r. Говорят, что Х функционально определяет Y, если каждому значению атрибутов кортежа отношения из Х соответствует не более одного значения атрибутов того же кортежа отношения из Y.
Такая ФЗ обозначается как
.Как видно из определения, функциональная зависимость инвариантна к изменению состояний базы данных во времени.
Пример. Понятие функциональной зависимости Продемонстрируем понятие функциональной зависимости на примере графика полетов аэропорта. ГРАФИК_ПОЛЕТОВ (Пилот, Рейс, Дата_вылета, Время_вылета)
| Иванов | 100 | 8.07 | 10:20 |
| Иванов | 102 | 9.07 | 13:30 |
| Исаев | 90 | 7.07 | 6:00 |
| Исаев | 100 | 11.07 | 10:20 |
| Исаев | 103 | 10.07 | 19:30 |
| Петров | 100 | 12.07 | 10:20 |
| Петров | 102 | 11.07 | 13:30 |
| Фролов | 90 | 8.07 | 6:00 |
| Фролов | 90 | 12.07 | 6:00 |
| Фролов | 104 | 14.07 | 13:30 |
Следовательно:
"Время_{} вылета"; "Рейс"; "Пилот".Важной задачей при выявлении функциональных зависимостей на атрибутах отношения, которое по определению является множеством, является выяснение, какой из атрибутов выступает как аргумент, а какой - как значение ФЗ. Наиболее подходящими кандидатами в аргументы ФЗ являются возможные ключи, так как кортежи представляют экземпляры сущности, которые идентифицируются значениями атрибутов своего ключа. Нестрого говоря, функциональная зависимость имеет место на отношении, когда значения кортежа на одном множестве атрибутов однозначным образом определяют значения кортежа на другом множестве атрибутов. Это рабочее определение ФЗ не содержит в себе тех формальных элементов, которые позволяют ответить на вопрос "А как проверить наличие ФЗ между атрибутами отношения?" Необходимый для этого формализм дает нам использование реляционных операций.
Для получения формального (строгого) определения н аличия ФЗ в отношении обратимся к реляционным операциям.
Определение 2. Пусть имеется отношение R со схемой r, X и Y - два подмножества R. ФЗ
имеет место на R, если множество имеет не более одного кортежа для каждого значения х. Такая ФЗ называется также F-зависимостью.Как видно из определения, формальная проверка наличия ФЗ
в отношении R состоит в выборе (селекции) отношения по значениям возможного ключа и установлении наличия однозначности между его значением и значениями других атрибутов.Алгоритм, который проверяет, удовлетворяет ли отношение R ФЗ
, состоит в сортировке отношения по значениям возможного ключа и установления факта однозначности между его значением и значениями других атрибутов. Этот алгоритм полезен, но он носит вспомогательный характер.Ясно, что если семантика предметной области базы данных сложна, то проверить кортежи на принадлежность к ФЗ достаточно сложно. Сложно вообще установить наличие самой функциональной зависимости, отвечающей природе рассматриваемых данных. С помощью такого формального метода можно выявить ФЗ, которые не являются реальными и носят случайный характер. Проектировщику реляционных баз данных следует знать о таком методе проверки наличия ФЗ, но при проектировании новой базы данных его применение малоэффективно. Он может быть полезен при реинжиниринге существующей базы данных.
Функциональные зависимости фактически представляют собой утверждения обо всех отношениях предметной области. Эти отношения могут являться значениями схемы r и, в сущности, не могут быть получены формальными методами. Единственный способ установления функциональных зависимостей для схемы отношения r - это исследование семантики атрибутов сущностей предметной области. Являясь высказываниями о сущностях предметной области, они не могут быть доказаны. Это обстоятельство по существу порождает неединственность представления предметной области отношениями реляционной БД.
Здесь уместно высказать гипотезу о том, почему бывают хорошие и плохие проекты баз данных.Во-первых, в силу субъективности подходов к анализу предметной области аналитики могут упустить важные ФЗ. Это может привести к тому, что, работая на множестве заведомо неэквивалентных схем, проектировщик создаст неудовлетворительный проект базы данных. Во-вторых, неединственность представления предметной области отношениями приводит к проблеме выбора из множества альтернатив. При этом схема базы данных, выбранная из набора эквивалентных схем, является правильной, но может организовывать данные для пользователя непривычным образом. В-третьих, можно определить ("накроить") схемы баз данных таким образом, что в результате операций с ФЗ будут потеряны и ФЗ, и сами данные.
Основы проектирования реляционных баз данных
Четвертая нормальная форма
Отношение находится в четвертой нормальной форме (4НФ), если оно находится в 3НФ или НФБК и все независимые многозначные ФЗ разнесены в отдельные отношения с одним и тем же ключом. Иными словами, 4НФ применяется при наличии в отношении более чем одной многозначной ФЗ и требует, чтобы отношение не содержало независимых многозначных ФЗ.Пример. Приведение к 4НФ
Рассмотрим отношение, содержащее сведения о кораблях (Ship), совершаемых ими рейсах (Voyage) и капитанах (Captain) (задано таблицей 6.3). Отношение представлено в таблице ниже и на рис. 6.6.
| Акбар | Иванов | Санкт-Петербург - Калининград |
| Акбар | Петров | Санкт-Петербург - Калининград |
| Акбар | Ивлев | Санкт-Петербург - Калининград |
| Акбар | Прохоров | Санкт-Петербург - Калининград |
| Акбар | Лазарев | Санкт-Петербург- Лондон |
| Акбар | Прохоров | Санкт-Петербург- Лондон |
| Жучка | Петров | Санкт-Петербург - Марсель |
| Жучка | Фролов | Санкт-Петербург - Стокгольм |
| Жучка | Ивлев | Санкт-Петербург - Стокгольм |
Рис. 6.6. Отношение с многозначными зависимостями
Отношение находится в НФБК и содержит только многозначные ФЗ. Однако имеет место аномалия удаления: если капитан Петров уйдет в отставку и все кортежи о нем будут удалены, то будут потеряны сведения о том, что корабль Жучка совершает рейсы Санкт-Петербург - Марсель. Если добавить новый рейс, то, возможно, придется ввести несколько кортежей в наше отношение.
Приведение отношения к 4НФ заключается в выделении для каждой многозначной ФЗ своего отношения, как показано на рис. 6.7.
Рис. 6.7. Отношение в 4НФ
Таким образом, процедура приведения отношения к 4НФ сводится к выполнению нескольких проекций, в данном случае двух проекций.
Нормализация отношений
Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной базы данных.Заметим, что с математической точки зрения задача построения как информационной модели предметной области, так и логической модели реляционной базы данных является результатом решения следующих комбинаторных задач:
Такие задачи имеют решения, допускающие большое число вариантов, и приводят к проблеме выбора рационального варианта из множества альтернативных вариантов схем отношений. Выбор наиболее рационального варианта обусловлен соблюдением различного рода соглашений и требований.
Перечень наиболее важных требований приведен ниже.
Создание системы, одновременно удовлетворяющей всем вышеназванным требованиям, представляет собой сложную оптимизационную задачу, которая подчас не имеет однозначного решения. Многие из требований находятся в противоречии друг к другу.
Так, например, требование производительности находится в противоречии к требованию гибкости. Требование минимизировать число отношений в базе данных находится в противоречии к требованию надежности данных.
В процессе эксплуатации реляционной базы данных происходит модификация данных: в отношениях добавляются или удаляются кортежи, в результате определенных событий изменяются значения некоторых атрибутов кортежей и т.п. После манипулирования данными значения некоторых атрибутов могут дублироваться, порождая избыточность данных, значения некоторых атрибутов могут удаляться, исчезая из базы данных, хотя потребность в этих значениях остается, некоторые значения атрибутов не могут быть добавлены, поскольку их значения неизвестны, т.е. данные в базе данных с течением времени становятся несогласованными и противоречивыми. Потенциальная противоречивость (или аномалии) при выполнении операций манипулирования данными в базе данных зависит как от типа ФЗ между атрибутами, так и от группировки этих атрибутов по отношениям.
Рассмотрим типичные примеры аномалий, возникающих при выполнении операций включения, удаления и модификации данных.
Пример. Аномалии операций над базой данных
ПОСТАВКИ (Поставщик, Адрес, Товар, Количество, Стоимость)
Обновление. Если Поставщик поставляет несколько видов товара, то значение атрибута Адрес повторяется для каждого кортежа и, следовательно, при изменении адреса поставщика необходимо изменить значение этого атрибута во всех этих кортежах. Иначе будет нарушена целостность данных базы данных.
Удаление. Если Поставщик прекращает поставку товаров на некоторое время, то кортежи со всеми его поставками удаляются. При этом происходит потеря реквизитов поставщика - Адреса и Наименования.
Вставка. Если договор на поставку уже заключен, а поставка еще не произведена, то невозможно включить в рассматриваемое отношение значения атрибутов Поставщик и Адрес, поскольку нет сведений о поставках (проблема интерпретации нуль-значений).
Подобные аномалии в данных лишь отчасти дают ответ на вопрос, почему логическая структура реляционной БД может быть неудовлетворительной.
Некоторые проблемы избыточности данных можно разрешить, заменив, например, исходное отношение ПОСТАВКИ на два новых отношения - отношение ПОСТАВЩИК (Поставщик, Адрес) и отношение ПОСТАВКА (Поставщик, Товар, Количество, Стоимость). Однако в целом остается ряд вопросов, на которые теория реляционных баз данных не дает удовлетворительных ответов: quot;Как найти хорошую замену для плохой схемы отношений? Как определить, является ли выбранная замена выгодной? Как создать схему, обеспечивающую наилучшую производительность?quot;
Например, для того чтобы выполнить запрос, использующий данные из двух таблиц, необходимо построить соединение этих таблиц, которое является дорогостоящей операцией с физической базой данных с точки зрения числа выполняемых операций ввода/вывода.
Теория функциональных зависимостей позволяет установить определенные требования к схемам отношений в реляционной базе данных. Эти требования формулируются в терминах свойств отношений и называются нормальными формами схем отношений. Каждая нормальная форма отношений связана с определенным классом ФЗ, которые представлены в отношениях. Понятно, что одним из очевидных способов устранения потенциальной противоречивости данных в отношениях логической модели реляционной базы данных является их разбиение на два или более отношений, в каждом из которых присутствует только одна ФЗ.
Это возможно, поскольку теория ФЗ утверждает, что существует минимальное покрытие множества ФЗ базы данных, т.е. минимальный набор ФЗ, из которых можно вывести все остальные. Каждой ФЗ из минимального покрытия можно отвести по самостоятельному отношению. Однако, во-первых, для заданного множества ФЗ может существовать несколько минимальных покрытий (выбор среди возможных альтернатив), и, во-вторых, для практики важно иметь наглядный способ построения минимального покрытия.
Процесс устранения потенциальной противоречивости и избыточности данных в отношениях реляционной базы данных называется нормализацией исходных схем отношений. Нормализация отношений заключается в выполнении декомпозиции или синтеза отношений, назначении ключей отношений в соответствии с определенными правилами, гарантирующими целостность отношений базы данных.
Требование минимальности числа отношений, т.е. построения минимального покрытия ФЗ обычно является опциональным. На минимальном покрытии, как правило, не может быть достигнута высокая производительность обработки запросов.
Почему нормализация схем отношений важна для проектирования реляционных баз данных? Многочисленные испытания показали, что нормализация схем отношений дает наилучший результат при моделировании предметной области с использованием реляционной модели данных; при этом не вводится большого числа ограничений, не искажаются данные. Таким образом, нормализация отношений является методом удаления из отношения ФЗ, которые приводят к аномалиям модификации данных. Иными словами, нормализация отношений помогает проектировать реляционную базу данных, которая не содержит избыточных данных и гарантирует их целостность.
Язык нормальных форм констатирует наличие или отсутствие определенных ФЗ в отношениях реляционной базы данных и указывает на уровень избыточности и надежности данных в нормализованных отношениях. Методы нормализации отношений основываются на применении понятия ФЗ и способов манипулирования ими. При выполнении реляционных операций над отношениями в базе данных каждый тип ФЗ может порождать определенный тип аномалий, который будет нарушать целостность данных в базе данных. Нормальная форма (НФ) представляет собой ограничение на схему базы данных, вводимое с целью устранения определенных нежелательных свойств при выполнении реляционных операций.
Различают несколько типов нормальных форм. Каждая из них ограничивает присутствие определенного класса ФЗ в отношении и устраняет присущие этому классу ФЗ аномалии в выполнении реляционных операций.
Примечание. Глагол quot;ограничиваетquot; в терминологии баз данных означает набор процедур, направленных на достижение определенных свойств объекта путем сужения области его действия.
Нормальная форма Бойса-Кодда
3НФ упрощает решение проблем контроля избыточности данных, интерпретации нуль-значений, контроля за операциями модификации данных, только если в отношениях отсутствуют какие-либо другие ФЗ, в частности обратные ФЗ неключевого атрибута на один из атрибутов составного первичного ключа или многозначные ФЗ. В противном случае вышеперечисленные проблемы остаются неразрешенными. Для устранения таких проблем, связанных с существованием обратных ФЗ неключевых атрибутов на часть составного ключа, была предложена усиленная 3НФ или НФ Бойса-Кодда.Отношение находится в нормальной форме Бойса-Кодда (НФБК), если оно находится в 3НФ, и в нем отсутствовали зависимости ключевых атрибутов от неключевых атрибутов. Иными словами, НФБК допускает наличие только таких нетривиальных ФЗ, в которых ключ определяет один или более других атрибутов:
, где 
включает некоторый ключ.Таким образом, схема отношения в НФБК обладает теми же достоинствами, что и схема в 3НФ, но устраняет некоторые дополнительные аномалии, не устраняемые 3НФ. Например, в отношение (Город, Адрес, Почтовый_индекс), находящееся в 3НФ, невозможно записать кортеж для города с известным почтовым индексом, если не известен адрес с этим почтовым индексом. Данное отношение не находится в НФБК, так как имеет место ФЗ Почтовый_индекс
Город, а атрибут почтовый_индекс не является ключом этого отношения.Замечание. В отличие от 3НФ, исходные отношения не всегда могут быть приведены в НФБК. Пример. Приведение отношения к НФБК
Продолжим рассмотрение примеров из области судоходства.
Допустим, что экипаж судна разделен на команды, каждая из которых отвечает за разные виды работ. Члены экипажа могут входить в разные команды, но в каждую команду входит только один руководитель. Команда может иметь несколько руководителей. Каждый член экипажа может руководить только одной командой. Отношение задается таблицей 6.1 ниже:
| Иванов | Наблюдение | Прохоров |
| Иванов | Питание | Макаров |
| Петров | Наблюдение | Леонтьев |
| Модин | Наблюдение | Прохоров |
| Васин | Питание | Лазарев |
| Фролов | Обслуживание | Сидоров |
| Ивлев | Обслуживание | Сидоров |
Отношение находится в 3НФ, однако содержит аномалию удаления. Если Петрова удалить из команды наблюдения, то будет потеряна информация о том, что Леонтьев является руководителем команды наблюдения, и при назначении нового члена экипажа в команду наблюдения не будет известно, что у нее есть еще один руководитель, кроме Прохорова.
Заметим, что в предыдущих случаях разбиение отношений происходило без создания избыточности данных из-за обратной зависимости атрибута на часть ключа. Приведение отношения к НФБК заключается в создании дополнительного отношения, содержащего сведения о руководителях команд (таблица 6.2).
| Наблюдение | Прохоров |
| Питание | Макаров |
| Наблюдение | Леонтьев |
| Питание | Лазарев |
| Обслуживание | Сидоров |
Рис. 6.5. Отношение в НФБК
Первая нормальная форма
Отношение находится в первой нормальной форме (1НФ), если все атрибуты отношения являются простыми (требование атомарности атрибутов в реляционной модели), т.е. не имеют компонентов. Иными словами, домен атрибута должен состоять из неделимых значений и не может включать в себя множество значений из более элементарных доменов. Так, например, дата не может считаться простым атрибутом. В большинстве случаев выполнить это требование достаточно просто. Каждый простой атрибут должен иметь свою колонку в таблице. Однако это часто приводит к дублированию данных в отношении.Типичным примером неатомарности атрибута являются так называемые повторяющиеся группы, представляющие массив значений атрибута.
Пример. Приведение отношения к 1НФ
На рис. 6.1 представлено ненормализованное отношение SHIPMENT (ОТГРУЗКА). Оно содержит повторяющиеся группы, представляющие массив значений, 1st Consignments, 2st Consignments, 3st Consignments (партии грузов). Атрибуты, характеризующие партию грузов (показаны на следующем рисунке), - Consignee (грузополучатель), Insured Value (застрахованная стоимость) и Declared Value (объявленная стоимость), - повторяются для каждой такой партии. Отметим, что для такого отношения следует ввести бизнес-правило, требующее, чтобы груз состоял не более чем из трех партий, поскольку четвертую партию вставить в этом отношении некуда.
Рис. 6.1. Ненормализованное отношение
Использование отношения, представленного не в 1НФ, может породить следующие проблемы:
Приведение отношения SHIPMENT к 1НФ заключается в изъятии данных о партиях груза из отношения SHIPMENT и создании для них связанного подчиненного отношения CONSIGNMENT (ПАРТИЯ_ГРУЗА). Результат приведения отношения SHIPMENT к 1НФ представлен на рис. 6.2. Для такого представления сущности SHIPMENT не требуется вводить ограничительное бизнес-правило, о котором упоминалось выше.
Рис. 6.2. Отношение в 1НФ
Таким образом, процедура приведения отношения к 1НФ состоит в вынесении неатомарных атрибутов в отдельное подчиненное отношение, т.е. в выполнении двух проекций.
Пятая нормальная форма
Как можно заметить, нормализация отношений выполнялась путем разложения (декомпозиции) схем отношений. Очевидно, что при таком подходе должен соблюдаться принцип обратимости: соединение проекций должно приводить к исходным отношениям. Это предполагает отсутствие потери кортежей; появление ранее не существовавших кортежей; сохранение ФЗ (семантика взаимосвязей между данными не должна нарушаться).Декомпозиция схем отношений не всегда гарантирует обратимость. Это обстоятельство связано с существованием класса ФЗ по соединению. Если отношение удовлетворяет ФЗ по соединению, то оно может быть восстановлено по своим проекциям. Отношения, содержащие более трех МФЗ, требуют особого внимания при построении логической модели реляционной базы данных. Также 4НФ не устраняет избыточность данных полностью, поэтому требуется дальнейшая декомпозиция схем отношений.
Отношение находится в пятой нормальной форме (5НФ), если оно находится в 4НФ и удовлетворяет зависимости по соединению относительно своих проекций. 5НФ называют также нормальной формой с проецированием соединений. Она используется для разрешения трех и более отношений, которые связаны более чем тремя ФЗ по типу quot;многие-ко-многимquot;.
Пример. Приведение к 5НФ
Рассмотрим отношение с несколькими многозначными зависимостями, представленное на рис. 6.8.
Рис. 6.8. Отношение с несколькими многозначными зависимостями
Рассмотрим сначала это отношение как три изолированных отношения со степенью связи quot;многие-ко-многимquot;:
Каждый автомобиль имеет определенный цвет и модель. Некоторые цвета характерны только для определенных моделей. Такие отношения разрешаются введением связывающих отношений, в данном случае таких отношений три:
Предположим, что клиент желает приобрести автомобиль синего цвета модели С, при этом марка автомобиля роли не играет. Запрос к базе данных на поиск такого автомобиля будет содержать два соединения между тремя таблицами Car, Car Color и Car Model по атрибуту наименование машины и два предиката: цвет = синий и модель = С.
Результат выполнения запроса будет удивителен: есть и Волга, и Жигули! Однако из таблицы Model Color видно, что автомобиля синего цвета модели С не существует. Появляется несуществующий кортеж. Такое явление представляет собой аномалию проецирования соединений и пример нарушения 5НФ.
Приведение отношения к 5НФ заключается во введении еще одного отношения, связывающего три исходных отношения, как показано на рис. 6.9.
Рис. 6.9. Отношение в 5НР
Таким образом, процедура приведения отношения, содержащего многозначные ФЗ, к 5НФ состоит в построении связывающего отношения, позволяющего исключить появление в соединениях ложных кортежей.
Следовательно, каждая нормальная форма ограничивает определенный тип ФЗ и устраняет аномалии обработки данных. Нормальные формы характеризуются следующими свойствами:
Литература: [2], [3], [15], [14], [16], [20], [31], [37], [39], [43], [44], [45].
Понятие о логической модели реляционной базы данных
Теперь, когда определены понятия отношения и операции над отношениями, уточним интуитивно используемое определение реляционной базы данных и ее схемы.Определение 1. Под реляционной базой данных принято понимать совокупность экземпляров конечных отношений. Совокупность схем отношений образует схему реляционной базы данных.
Схема реляционной базы данных является логической моделью реляционной базы данных.
Как уже было сказано в лекции 2 - "Предметная область базы данных и ее модели", - на основе информационной модели в процессе проектирования создаются логическая и физическая модели данных. Информационная модель данных отражает потребности системы в данных и связи между данными с точки зрения их потребителей - пользователей; логическая модель данных является независимым логическим представлением данных; физическая модель данных содержит определения всех реализуемых объектов в конкретной базе данных для конкретной СУБД.
На практике часто рассматривают только две модели - логическую и физическую модели данных. При этом информационная и логическая модели данных не различаются и считаются синонимами. В рамках такого подхода некоторые специалисты в области баз данных считают, что информационная модель данных должна быть нормализована. Это означает, что проектировщики баз данных должны требовать от аналитиков, чтобы они приводили информационную модель данных к третьей нормальной форме! Такой подход имеет ряд недостатков. Во-первых, аналитики, являясь экспертами в предметной области, как правило, не представляют, что такое нормализация данных. Во-вторых, информационная модель данных должна быть независимой от физической модели данных, в рамках которой она будет реализовываться. Для реализации информационной модели данных может быть выбрана не реляционная, а, например, сетевая (СУБД ADABAS) или многомерная (СУБД Teradata) модели данных, тогда нормализация отношений модели не столь актуальна. В-третьих, проектировщики базы данны х должны иметь логическое представление данных, посредством которого, с одной стороны, общаться с аналитиками и пользователями в понятных для них терминах, и, с другой стороны, превращать полученные логические отношения в физические объекты базы данных.
Поэтому в настоящем курсе рассматривается три уровня моделей данных, а процесс нормализации информационной модели данных считается составной частью процесса создания логической модели данных, которую предполагается реализовать на реляционной СУБД.
На практике при построении логической модели реляционной базы данных особое значение для решения задачи формирования отношений базы данных имеет понятие функциональной зависимости (ФЗ). Установление ФЗ и получение наилучшего с точки зрения минимальности представления множества ФЗ позволят построить наиболее оптимальный вариант базы данных, обеспечивающий надежность хранения и обработки данных на основе методов эквивалентных преобразований схем отношений реляционной базы данных.
Процесс решения такой задачи называется нормализацией отношений информационной модели предметной области и заключается в превращении ее объектов в логические таблицы базы данных.
Третья нормальная форма
Отношение находится в третьей нормальной форме (3НФ), если оно находится во 2НФ, и все неключевые атрибуты отношения зависят только от первичного ключа. Иными словами, 3НФ требует, чтобы отношение не содержало транзитивных ФЗ неключевых атрибутов от ключа.Формально это требование можно сформулировать следующим образом: схема отношения R находится в 3НФ, если не существует ключа Х для R, множества атрибутов
и неключевого атрибута А из R, не принадлежащего Х или Y, таких, что: 1) имеет место в R, 2) 
имеет место в R, но 3) не имеет места в R.ФЗ представляют не только ограничения целостности, налагаемые на отношения, но и связи между атрибутами, если они (связи) сохраняются в базе данных. Если отношение содержит частичную зависимость
- ключ отношения и , то в каждом кортеже, используемом для хранения связи значений Х со значениями какого-либо другого атрибута, кроме А и Х, должна появиться связь между Y и A. Так, например, адрес поставщика дублируется для каждого поставляемого товара в отношении ПОСТАВКИ. Использование 3НФ исключает возможность возникновения такой ситуации (см. условие 3 в формальном определении 3НФ).Наличие транзитивной зависимости
не позволяет связать значения Y и Х, если не существует значения А, связанного со значением Y. Это затрудняет вставку и обновление данных, которые необходимо выполнить сразу для пары связей, а в случае удаления данных приводит к потере связи.Пример. Приведение отношения к 3НФ
Вновь обратимся к рассмотрению отношения SHIPMENT, представленного на рис. 6.3. Оно содержит транзитивную ФЗ: атрибут Customs Declaration (таможенная декларация) является по своей сути свойством атрибутов Origin (пункт отправления) и Destination (пункт назначения). Результат приведения отношения SHIPMENT к 3НФ представлен на рис. 6.4.
Рис. 6.4. Отношение в 3НФ
Таким образом, процедура приведения отношения к 3НФ состоит в выполнении двух проекций: проекции по правой части транзитивной ФЗ и проекции по левой части транзитивной ФЗ.
Вторая нормальная форма
Будем считать атрибут отношения ключевым, если он является элементом какого-либо ключа отношения. В противном случае атрибут будет считаться неключевым атрибутом. Так в отношении (Город, Адрес, Почтовый_индекс) все атрибуты являются ключевыми, поскольку при заданных ФЗ город, адрес почтовый_индекс и почтовый_индекс \to город ключами являются пары город, адрес и адрес, почтовый_индекс.Отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и все неключевые атрибуты отношения функционально полно зависят от составного ключа отношения. Иными словами, 2НФ требует, чтобы отношение не содержало частичных ФЗ.
Пример. Приведение отношения ко 2НФ
Вновь обратимся к рассмотрению отношения SHIPMENT, представленного на рис. 6.2. Оно содержит частичную ФЗ: неключевой атрибут Ship Capacity (грузоподъемность корабля) не зависит от ключевого атрибута Departure Date (даты убытия), а зависит от ключевого атрибута Ship Registration Number (регистрационный номер корабля).
Использование отношения, представленного не во 2НФ, может породить следующие проблемы:
Приведение отношения SHIPMENT ко 2НФ заключается в изъятии атрибутов частичной ФЗ из отношения SHIPMENT и создании для нее связанного подчиненного отношения SHIP. Результат приведения отношения SHIPMENT ко 2НФ представлен на рис. 6.3.
Рис. 6.3. Отношения во 2НФ
Таким образом, процедура приведения отношения ко 2НФ состоит в выполнении двух проекций: проекции без атрибутов частичной ФЗ и проекции на часть составного ключа и те атрибуты, которые от него зависят.
Основы проектирования реляционных баз данных
Алгоритм метода декомпозиции отношений
Теперь нам известно, с чего начать нормализацию - с универсального отношения; что проверить - нахождение исходного отношения в НФБК; что предпринять - декомпозицию исходного отношения на два других отношения; и когда остановиться - все отношения базы данных в НФБК. Таким образом, можно сформулировать общий алгоритм проектирования логической модели реляционной базы данных методом декомпозиции:Алгоритм метода декомпозиции отношений
Алгоритм
Уточним некоторые аспекты метода декомпозиции.
Во-первых, как выполнить декомпозицию отношения на два отношения. Пусть отношение R(A, B, C, D, ...) содержит ФЗ
и, следовательно, не находится в НФБК. Атрибут С является детерминантом, но не возможным ключом. Для выполнения декомпозиции отношения R создаются два отношения R1(A, B, C, ...) и R2(C, D), в одно из которых выделяется ФЗ . Такая декомпозиция является декомпозицией без потерь при естественном соединении. Далее с тех же позиций рассматриваются отношения R1 и R2.Во-вторых, каков критерий выбора ФЗ для выполнения проекции (далее мы увидим, насколько это может быть существенно). Понятно, что в качестве кандидатов для осуществления проекции следует отбирать ФЗ с детерминантами в левой части. Однако зависимости с детерминантами могут носить транзитивный характер, и здесь полезно применить первое эмпирическое правило выбора ФЗ для выполнения проекции - "правило цепочки". Правило цепочки состоит в следующем:
Если
, то в качестве ФЗ для осуществления проекции используется крайняя правая зависимость или "конец цепочки" .Алгоритм метода синтеза отношений
В данном разделе приводится лишь некоторый обзор алгоритма синтеза отношений.Мы уже рассматривали примеры декомпозиции с потерей ФЗ. Причиной потери ФЗ является некоторая ФЗ
, которая не может быть исключена из множества F-зависимостей, связанных с получаемыми отношениями R1 или R2. Таким образом, суть проблемы сводится к нарушению замкнутости реляционных операций над ФЗ на полученной схеме базы данных. Для того чтобы ее решить, необходимо пополнить минимальное покрытие ФЗ, или, как говорят, усилить минимальное покрытие.На пути решения этой проблемы было бы неплохо усилить все ФЗ, связав их с уникальными ключами, скажем, описывая для них уникальные индексы. Тогда можно контролировать целостность базы данных. Для этого нужно усилить минимальное покрытие. Грубо говоря, усиливаемость минимального покрытия означает, что выделено множество первичных ключей и все ФЗ из минимального покрытия пересмотрены в призме этого множества с точки зрения выводимости ФЗ рассматриваемой базы данных.
Введем определение.
Определение 4. Реляционная база данных называется полной, если:
Почти всегда в предметной области базы данных можно выделить набор отношений, обладающих свойством полноты. Доказана теорема [Мейер], что существует алгоритм, который выводит полную базу данных из множества заданных ФЗ.
Поскольку такой алгоритм строит схему базы данных непосредственно из заданного набора ФЗ, он называется алгоритмом синтеза базы данных. При этом на первый план выступает проблема правильного представления отношения с заданной схемой своими проекциями, т.е. соединения по результирующей схеме базы данных могут оказаться ложными. Однако если минимальное покрытие исходного набора ФЗ будет усилено, то подобного явления можно избежать.
Пример. Универсальный ключ и ложные соединения
Пусть отношение R имеет кортежи:
| 1 1 1 1 | 4 1 2 2 |
Случай 1.
Отсутствие ложных соединений
Разбиение на отношения
R1=ABC и R2=BCD
Случай 2. Наличие ложных соединений
Разбиение на отношения
R1 = AB и R2= BCD
ABCD
| 1 1 1 1 | 1 1 2 2 |
| 4 1 1 1 | 4 1 2 2 |
, то решить проблему можно, введя универсальный ключ {A,C}. Тогда можно добавить в исходную схему отношениеAC
Заметим, что атрибут А выступает в качестве ключа практически во всех ФЗ. Выделенный или добавленный атрибут, обладающий подобным свойством, называется универсальным ключом. Таким образом, решение проблемы ложных соединений заключается в добавлении подсхемы, которая содержит универсальный ключ, и выполнении соединения с ее использованием.
Теперь можно перейти к обзору алгоритма синтеза реляционной базы данных.
Теоретически показано, что для того, чтобы синтезировать полную базу данных, необходимо построить кольцевое минимальное покрытие для исходного набора ФЗ.
Введем некоторые обозначения. Составной ФЗ называется ФЗ:
, где Y может быть пусто. С каждой составной ФЗ можно связать набор ФЗ: 
. Пусть С - множество составных ФЗ, fd(C) - множество всех ФЗ, связанных с ФЗ из С.В принятых обозначениях основные этапы алгоритма синтеза отношений приведены ниже.
Алгоритм поэтапного синтеза отношений
Вход: F - множество ФЗ предметной области базы данных
Выход: схема полной базы данных
Этап 1. Нахождение неизбыточного покрытия F1 для F
Для каждой ФЗ из F проверяется, может ли данная ФЗ быть выведена из оставшихся ФЗ. Если да, то ФЗ удаляется. Этап завершается после перебора всех ФЗ из F. В результате выполнения этапа получается множество ФЗ F1.
Этап 2. Сокращение слева элементов F1
Удаляются последовательно один за другим атрибуты из левых частей ФЗ F1; проверяется, может ли полученная ФЗ быть выведена из исходных ФЗ F1. Если да, то исходная ФЗ заменяется на новую ФЗ. Этап завершается после перебора всех ФЗ F1.
В результате получается множество ФЗ F2.
Этап 3. Сокращение справа элементов F2
Удаляются последовательно один за другим атрибуты ФЗ из правых частей ФЗ F2; проверяется, может ли исходная ФЗ быть выведена из полученной ФЗ и имеющихся ФЗ F2. Если да, то исходная ФЗ заменяется на новую ФЗ. Этап завершается после перебора всех ФЗ F2. В результате получается множество ФЗ F3.
На этом сокращение ФЗ закончено. Избыточность отсутствует. Необходимо приступать к построению минимального покрытия.
Этап 4. Разделение F3 на классы эквивалентности по правым частям
Строится разбиение F3 на группы: две ФЗ принадлежат одной и той же группе тогда и только тогда, когда их правые части эквивалентны. В результате получается множество классов эквивалентности ФЗ
.Этап 5. Удаление в классах эквивалентности избыточных ФЗ
Для всех пар ФЗ fdi и fdj из одной и той же группы проверяется, может ли ФЗ левой стороны fdj от правой стороны fdj быть выведена из этой группы ФЗ. Если да, то из fdj ФЗ удаляется и добавляется в правую часть этой ФЗ к правой fdi. Новая ФЗ будет находиться в той же группе, что и исходная ФЗ. В результате получается минимальное число ФЗ F5, покрывающих F3.
Этап 6. Получение классов эквивалентности по левым частям F5 и составных ФЗ C1
Для каждого множества ФЗ с эквивалентными левыми частями из F5 создается составная ФЗ
. Если какой-либо атрибут из Y есть в Xi, то этот атрибут удаляется. В результате получается множество составных ФЗ С1.Этап 7. Удаление избыточных зависимостей из С1
Для каждой составной ФЗ из С1 и для каждого атрибута Xi из левой части С сдвигаются атрибуты в правую часть. В результате получается множество составных ФЗ С'. Если fd(C') эквивалентно fd(C1), то С1 заменяется на С'. В результате получается множество ФЗ С2.
Этап 8. Формирование кольцевого минимального покрытия
Для каждой составной ФЗ c из С2 и каждого атрибута A из правой части c удаляется атрибут А. В результате получается С', состоящее из с'. Если fd(C') эквивалентно fd(C2), то С2 заменяется на С'.В результате получается множество ФЗ С3.
Этап 9. Формирования схемы полной базы данных
Для каждой составной ФЗ с из С3 формируется таблица атрибутов, которые появляются в с. Ключами для этой таблицы являются Хi из левой части с. Таблица послужит для усиления ФЗ в F.
Алгоритм поэтапного синтеза отношений обладает хорошей сходимостью, его целесообразно использовать в запрограммированном виде. Для этого можно воспользоваться уже готовой программой, или написать свою программу с учетом специфики своих задач, обратившись к монографии Д. Мейера [3].
В результате получается множество ФЗ С3.
Этап 9. Формирования схемы полной базы данных
Для каждой составной ФЗ с из С3 формируется таблица атрибутов, которые появляются в с. Ключами для этой таблицы являются Хi из левой части с. Таблица послужит для усиления ФЗ в F.
Алгоритм поэтапного синтеза отношений обладает хорошей сходимостью, его целесообразно использовать в запрограммированном виде. Для этого можно воспользоваться уже готовой программой, или написать свою программу с учетом специфики своих задач, обратившись к монографии Д. Мейера [3].
Пример. Применение алгоритма синтеза
Пример иллюстрирует работу алгоритма на каждом из его этапов.
, то 
может быть удалена.
, тогда или A, или B могут быть удалены из 
. или выводится из F1 следующим образом: Из 
(по аддитивности); из 
и 
(по транзитивности).
, тогда С может быть удалена из 
. Из и 
(по транзитивности); из 
(по аддитивности).
. Тогда так как 
, то имеется одна группа 
. Так как 
(по расширяемости и аддитивности), то другая группа есть 
. и 
Так как 
принадлежит к другой группе, чем 
и 
, то последние ФЗ могут быть заменены на .
.
. Сдвигаем A,B в правую часть с и получаем с' = (A;B). Тогда 
. A,B может быть удалена из с, так как они есть в левой части с'. Так как 
могут быть выведены из 
, то с может быть заменена на с'.
. 
. D удаляется из 
и 
. 
. Так как 
может быть выведена из 
, то С2 может быть заменена на С'.
. Тогда первое отношение есть ABCD c ключом (A,{B,C}); второе отношение есть BD с ключом {B}; третье отношение есть FG с ключом {F,G}.Выводы
Создание логической модели реляционной базы данных методом декомпозиции: преобразование ER-диаграмм в отношения базы данных
Практика проектирования реляционных баз данных методом декомпозиции отношений показала ряд его недостатков, связанных с потерей данных при соединениях и с потерей ФЗ. Однако метод декомпозиции достаточно прост для понимания, нагляден, легко реализуется в инструментальных CASE-средствах проектирования и в настоящее время является наиболее часто применяемым при проектировании баз данных.
Для построения логических моделей реляционных баз данных методом декомпозиции сформулирован ряд правил, получивших название правила преобразования ER-диаграмм в отношения базы данных. Правила позволяют исключить потенциальные недостатки метода декомпозиции и нацелены на приведения схемы отношений базы данных к нормальным формам.
Рассмотрим правила преобразования на примере базы данных о преподавателях, читающих лекции в институте. Сущность Преподаватель соотносится с сущностью Предмет посредством связи Читает. При этом возможны следующие варианты поведения данной предметной области:
Возможны варианты с иной степенью связи, например когда каждый преподаватель может читать несколько курсов.
Каждый из этих вариантов может быть представлен ER-диаграммой. Однако следует помнить, что каждая ER-диаграмма представляет свой собственный набор правил поведения предметной области и только одна из них может быть истинной в каждый момент времени.
Если степень бинарной связи определена, то предварительные отношения могут быть получены путем просмотра нескольких альтернатив и выбора варианта, наиболее подходящего с точки зрения правил предметной области и личных предпочтений проектировщика. Определяющими признаками выбора одного из альтернативных вариантов представления отношения являются степень связи и класс принадлежности сущности.
Сформулируем первое правило.
Правило 1. Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей является обязательным, то требуется построение только одного отношения. При этом первичным ключом отношения может быть ключ любой сущности.
Исходное отношение является одновременно и конечным отношением.
Пример.
ПРЕПОДАВАТЕЛЬ (Табельный_номер, Фамилия, Предмет, Количество_часов)
Это правило может быть применено для первого варианта поведения предметной области, когда исходное отношение не требует декомпозиции, так как не содержит избыточных данных и нуль-значений.
Сформулируем второе правило.
Правило 2. Если степень бинарной связи 1:1 и класс принадлежности одной сущности является обязательным, а другой сущности - не обязательным, то требуется построение двух отношений - по одному на каждую сущность. При этом первичным ключом каждого отношения является ключ его сущности, а ключ сущности с необязательным классом принадлежности добавляется в отношение для сущности с обязательным классом принадлежности в качестве атрибута (миграция ключа). Пример.
Исходное отношение:
ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов)
Результирующие отношения:
ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия, Предмет) ПРЕДМЕТЫ (Предмет, Количество_часов)
Это правило может быть применено во втором варианте, когда исходное отношение уже требует декомпозиции. Исходное отношение ПРЕПОДАВАТЕЛЬ_1 содержит проблему нуль-значений: данные о предметах, которые не читаются в данный момент, не могут быть внесены в базу данных.
Результирующее отношение ПРЕПОДАВАТЕЛЬ_2 не имеет проблемы нуль-значений.
В результирующем отношении ПРЕДМЕТЫ эта проблема исключается: для предмета, который в данный момент не читается, определяется специальное непустое значение по умолчанию. Миграция ключа необходима для восстановления исходного отношения. Таким образом, миграция ключа в методе декомпозиции представляет собой перенос первичного ключа одного отношения в другое отношение для предотвращения потери данных при соединении.
Сформулируем третье правило.
Правило 3. Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей не является обязательным, то требуется построение трех отношений - по одному на каждую объектную сущность и одному для связывающего отношения. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи, с первичным ключом, составленным из ключей объектных сущностей.Пример.
Исходное отношение:
ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов)
Результирующие отношения:
ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов) ЧИТАЕТ (Табельный_номер, Предмет)
Это правило можно применить в третьем варианте поведения предметной области, когда исходное отношение необходимо разбить на три отношения. Разбиение на два отношения не позволит исключить проблему нуль-значений. В случае трех отношений такая проблема исключается: в отношение ПРЕДМЕТЫ для предмета, который в данный момент не читается, определяется непустое значение по умолчанию.
Сформулируем четвертое правило.
Правило 4. Если степень бинарной связи 1:N, и класс принадлежности n-связной сущности является обязательным, то достаточно построить два отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения, а ключ 1-связной сущности добавляется в отношение для n-связной сущности в качестве атрибута.
Пример.
Исходное отношение:
ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов)
Результирующие отношения:
ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов, Табельный_номер)
Сформулируем пятое правило.
Правило 5. Если степень бинарной связи 1:N и класс принадлежности n-связной сущности не является обязательным, то необходимо построить три отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи. Ключи сущностей должны быть атрибутами последнего отношения. Пример.
Исходное отношение:
ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов)
Результирующие отношения:
ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов) ЧИТАЕТ (Предмет, Табельный_номер)
Отметим, что если степень бинарной связи 1:N, то фактором, определяющим выбор одного из правил (правила 4, 5), является класс принадлежности n-связной сущности. Класс принадлежности 1-связной сущности не влияет на конечный результат декомпозиции. В ситуации правила 4 имеет место проблема нуль-значений по атрибуту Предмет, в ситуации правила 5 имеет место проблема нуль-значений по атрибутам Предмет и Преподаватель. Поэтому во избежание дублирования и нуль-значений в ситуации правил 4 и 5 необходимо строить два и три результирующих отношения соответственно. Миграция ключа 1-связной сущности выполняется для восстановления исходного отношения при соединении.
Если степень бинарной связи N:M, то во избежание дублирования и нуль-значений необходимо всегда строить три отношения. Сформулируем шестое правило.
Правило 6. Если степень бинарной связи M:N, то необходимо построить три отношения - по одному для каждой сущности и одно отношение для связи. При этом ключ каждой сущности является первичным ключом соответствующего отношения, и входит в составной первичный ключ отношения для связи. Пример.
Исходное отношение:
ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов)
Результирующие отношения:
ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов) ЧИТАЕТ (Предмет, Табельный_номер)
Для отношения с трех- и более сторонней связью во избежание избыточности и нуль-значений требуется построение не менее четырех отношений.
Сформулируем седьмое правило.
Правило 7. Если связь является трехсторонней, необходимо построить четыре отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи. Ключи сущностей должны быть атрибутами последнего отношения.
Аналогично для отношения с n-сторонней связью требуется построение n+1 отношений.
Отметим, что все вышесформулированные правила построены по одному общему принципу: каждому неключевому атрибуту - свое отношение, т.е. миграция неключевых атрибутов запрещена.
Следует помнить, что после предварительного разбиения исходного отношения необходимо показать, используя ФЗ и ключи отношений, что полученная схема реляционной базы данных находится в НФ Бойса-Кодда (НФБК) (или 3НФ). Только тогда полученная схема отношений может считаться окончательной. Обычно проектировщики баз данных при использовании метода декомпозиции не выполняют таких действий, так как в большинстве случаев (но не всегда!) применение правил преобразования дает НФБК.
В некоторых случаях может оказаться, что для создания логической модели предметной области базы данных недостаточно имеющихся сущностей и связей. Одним из них является ситуация, когда экземпляры одной сущности играют разные роли (супертип/подтип) в предметной области базы данных. Это обусловливается наличием между экземплярами сущности отношения иерархии или агрегации по включению. При этом сущность представляет собой множество с отношением порядка на экземплярах, что приводит к наличию классов эквивалентности, имеющих различную семантическую интерпретацию в предметной области.
Так, например, база данных кафедры института содержит две категории служащих - преподаватели и заведующий кафедрой. Заведующий кафедрой также может читать лекции по предметам, но получает обычно фиксированный оклад; преподаватели имеют почасовую ставку оплаты. Попробуем представить информацию о служащих кафедры более подходящим образом. Выделим для каждой категории служащих кафедры отдельную сущность и рассмотрим ER-диаграмму Зав.
кафедрой Руководит Преподавателями.
При этом ключом каждой сущности будет являться табельный номер служащего. Поскольку связь Руководит имеет степень 1:N, и класс принадлежности обеих сущностей является обязательным, то согласно правилу 4 достаточно построить два предварительных отношения. Поскольку неключевые атрибуты Фамилия и Адрес_служащего помещены в оба предварительных отношения, то согласно общему принципу правил преобразования они должны быть переопределены для одного из отношений. Переименование атрибутов в одном из отношений порождает проблему ответа на запрос: для того чтобы найти домашний телефон конкретного служащего, необходимо пересмотреть оба отношения и построить объединение результатов просмотра. Таким образом, переименование атрибутов, к которому иногда поспешно прибегают проектировщики, не является хорошим решением.
Рассмотрим иной вариант представления данных о служащих кафедры. Будем считать заведующего кафедрой и преподавателей служащими, и представим их функции как роли, которые данный служащий может играть. Тогда Отношение СЛУЖАЩИЙ представляет собой родительское отношение - супертип для двух подчиненных отношений - подтипов ЗАВ. КАФЕДРОЙ и ПРЕПОДАВАТЕЛЬ, которые соединяются связью Руководит (см. рис. 7.1).
Рис. 7.1. Отношение "супертип/подтип"
Родительское отношение - супертип - содержит общие с подчиненными отношениями-подтипами атрибуты. Подчиненные отношения - подтипы содержат специфическую для их ролей информацию. Каждое порождаемое ролью отношение связано с общим отношением через атрибут общего домена, в данном случае табельный номер. Окончательный набор отношений будет состоять из трех отношений.
Результирующие отношения:
СЛУЖАЩИЙ (#служащий, общие атрибуты для всех служащих) ЗАВЕДУЮЩИЙ (#заведующий, .... ) ПРЕПОДАВАТЕЛЬ (#преподаватель, ..., #заведующий)
Заметим, что связь, которая соединяет две роли одной исходной сущности, называется рекурсивной (служащие руководят служащими). Связь, которая соединяет роли двух различных сущностей, не является рекурсивной.
Чтобы избежать поиска с целью выявления типа работы служащего, можно ввести в родовое отношение дополнительный атрибут, определяющий, кем является служащий. Несмотря на то, что с точки зрения теории реляционных баз данных такой прием приводит к избыточности данных, к нему прибегают в целях увеличения производительности системы.
Сформулируем восьмое правило.
Правило 8. Исходная сущность служит источником генерации одного отношения. Ключ сущности есть ключ отношения. Подчиненные сущности (ролевые элементы) и связи, соединяющие их, порождают такое количество отношений, которое определяется набором правил 1-7, причем каждый ролевой элемент трактуется как обычная сущность.
Декомпозиция схем отношений, свойства соединения без потерь и сохранения ФЗ
Одной из целей проектирования реляционной базы данных является построение декомпозиции (разбиения) универсального отношения на совокупность отношений, удовлетворяющих требованиям нормальных форм.Введем определение декомпозиции схемы отношения.
Определение 1. Декомпозицией схемы отношений
называется замена ее совокупностью 
подмножества R, таких, что 
.Прежде чем перейти к изучению метода декомпозиции схем отношений, рассмотрим проблему соединения отношений при разбиении универсального отношения. Когда мы заменяем исходное отношение на два других взаимосвязанных отношения, правомерно предположить, что эти отношения будут представлять собой проекции исходного отношения на соответствующие атрибуты. Единственный способ выяснить, содержат ли полученные проекции ту же информацию, что и исходное отношение, - восстановить ее, выполнив естественное соединение полученных проекций. Если отношение, полученное в результате выполнения соединения, не будет совпадать с исходным отношением, то невозможно сказать, какое из них является первоначальным отношением для данной схемы. Таким образом, проблема заключается в том, что при соединении можно потерять существующие или приобрести ранее не существовавшие ложные кортежи. Рассмотрим пример декомпозиции с потерей информации.
Пример. Декомпозиция с потерей информации
Атрибуты А и В не зависят функционально от атрибута С.
Говорят, что декомпозиция
схемы отношения r обладает свойством соединения без потерь относительно множества ФЗ D, если каждое отношение R, удовлетворяющее D, может быть представлено в виде:
Пусть
. Тогда для отображений проекции-соединения справедливы следующие свойства:
Эти свойства следуют из определения естественного соединения. Первое свойство используется при проверке, обладает ли декомпозиция свойством соединения без потерь относительно некоторого множества ФЗ.
Рассмотрим алгоритм проверки свойства соединения без потерь.
Алгоритм. Проверка декомпозиции на свойство соединения без потерь
input: схема отношения R(A1, A2, ..., Ak), множество ФЗ F, декомпозиция d={R1, R2, ..., Rk}.
output: Булева переменная истина или ложь.
Алгоритм
, ищем строки, которые совпадают по всем столбцам, соответствующим атрибутам из Х. При обнаружении таких строк отождествляем их символы в столбцах, соответствующих атрибутам из Y, по правилу aj в aj, bij в bij.Приведенный алгоритм позволяет корректно определить, обладает ли декомпозиция свойством соединения без потерь.
Рассмотрим пример применения алгоритма, используя отношение ПОСТАВКИ (Поставщик, Адрес, Товар, Стоимость). Обозначим его атрибуты как: А - поставщик, В - адрес, C - товар, D - стоимость, при этом имеют место ФЗ
.Пример. Проверка декомпозиции на свойство соединения без потерь
Схема отношения
| a1 | a2 | b13 | b14 |
| a1 | b22 | a3 | b4 |
, и две строки совпадают по А, то можно отождествить их символы для А: b22 на a2. В итоге имеем таблицу| a1 | a2 | b13 | b14 |
| a1 | a2 | a3 | a4 |
При декомпозиции одной схемы отношения на две другие схемы отношений используется более простая проверка: декомпозиция обладает свойством соединения без потерь, если только
. Такая ФЗ должна принадлежать F+.Свойство соединения без потерь гарантирует, что любое отношение может быть восстановлено из его проекций. Понятно, что при декомпозиции ФЗ исходной схемы отношения распределяются по новым отношениям. Поэтому важно, чтобы при декомпозиции множество ФЗ F для схемы отношения r было выводимым из проекций на схемы Ri.
output: Булева переменная истина или ложь.
Алгоритм
, ищем строки, которые совпадают по всем столбцам, соответствующим атрибутам из Х. При обнаружении таких строк отождествляем их символы в столбцах, соответствующих атрибутам из Y, по правилу aj в aj, bij в bij.Приведенный алгоритм позволяет корректно определить, обладает ли декомпозиция свойством соединения без потерь.
Рассмотрим пример применения алгоритма, используя отношение ПОСТАВКИ (Поставщик, Адрес, Товар, Стоимость). Обозначим его атрибуты как: А - поставщик, В - адрес, C - товар, D - стоимость, при этом имеют место ФЗ
.Пример. Проверка декомпозиции на свойство соединения без потерь
Схема отношения
| a1 | a2 | b13 | b14 |
| a1 | b22 | a3 | b4 |
, и две строки совпадают по А, то можно отождествить их символы для А: b22 на a2. В итоге имеем таблицу| a1 | a2 | b13 | b14 |
| a1 | a2 | a3 | a4 |
При декомпозиции одной схемы отношения на две другие схемы отношений используется более простая проверка: декомпозиция обладает свойством соединения без потерь, если только
. Такая ФЗ должна принадлежать F+.Свойство соединения без потерь гарантирует, что любое отношение может быть восстановлено из его проекций. Понятно, что при декомпозиции ФЗ исходной схемы отношения распределяются по новым отношениям. Поэтому важно, чтобы при декомпозиции множество ФЗ F для схемы отношения r было выводимым из проекций на схемы Ri.
Некоторые проблемы метода декомпозиции
Алгоритм метода декомпозиции отношений не является совершенным. Мир ФЗ очень разнообразен. Он представляет собой хороший рабочий инструмент и, учитывая типы ФЗ, может совершенствоваться. Обратим внимание на две проблемные ситуации, связанные с применением метода декомпозиции. Пусть имеется отношение R(A, B, C, D, ...) из примера выше.Первая ситуация: в процессе декомпозиции потеряна ФЗ
, и если отношения R1 и R2 будут использованы для создания базы данных, то нельзя гарантировать, что связи между этими атрибутами будут внесены в БД корректно. Отсюда вытекает второе эмпирическое правило выбора ФЗ для выполнения проекции: не следует использовать ФЗ в качестве ФЗ для осуществления проекции, если ее левая часть является детерминантом другой ФЗ. Эта проблема разрешается путем применения правила цепочки.Вторая ситуация: один атрибут зависит от двух детерминантов - один возможный ключ {A, C} и два детерминанта А и С. Эта ситуация является более критичной. Отношение не находится в НФБК; в отношении отсутствуют цепочки ФЗ, и правило цепочек к нему неприменимо. Эта проблема не разрешается с помощью стандартного метода декомпозиции. Решением является разложение исходного отношения на два отношения, в основе которого лежит утверждение о том, что все ФЗ с одинаковыми детерминантами необходимо выделять в отдельные группы и каждой такой группе отводить свое собственное отношение. Полученные отношения следует проверять на соответствие НФБК. Такой подход к проектированию логической модели реляционной базы данных получил название метода синтеза. Метод синтеза может использоваться как самостоятельно, так и в сочетании с методом декомпозиции по проекции. Приведенные примеры позволяют понять ряд потенциальных недостатков декомпозиции как метода проектирования лог ических моделей реляционных баз данных.
Прежде чем перейти к изучению метода синтеза, рассмотрим использование элементов синтеза в декомпозиции. Как можно было заметить, декомпозиция осложняется при наличии транзитивных ФЗ. Особенностью транзитивной ФЗ является ее избыточность. ФЗ принято считать избыточной, если она содержит в себе информацию, которая может быть получена из других ФЗ базы данных. Исключение избыточной транзитивной ФЗ из базы данных может быть выполнено без отрицательного воздействия на ее результаты. Избыточность присуща не только транзитивным ФЗ и, следовательно, избыточные ФЗ желательно исключать до применения алгоритма декомпозиции.
Понятие о методах декомпозиции отношений
Предположим, что схема базы данных содержит F-зависимости. Из положений теории о F-зависимостях следует, что если отношения базы данных находятся в нормальной форме Бойса-Кодда (НФБК), то проектирование логической модели базы данных можно считать завершенным в этом классе зависимостей. Как видно, теория дает полезный (!) критерий останова проектирования.Сформулируем наглядный критерий, позволяющий определить, находится ли отношение в НФБК. Для этого введем следующее вспомогательное понятие.
Определение 3. Пусть дана ФЗ:
, и В функционально не зависит от любого подмножества А, тогда А называется детерминантом В.Детерминантами в отношениях являются атрибуты левых частей ФЗ. Возможные ключи (см. учебный элемент "Реляционная модель данных") идентифицируются путем нахождения минимального множества значений атрибутов, которые определяют значения всех остальных атрибутов в отношении. Напомним понятие возможного ключа отношения как атрибута или атрибутов данного отношения, который (-ые) могут быть в данном отношении выбраны в качестве первичного.
Тогда критерий Кодда, позволяющий определить, находится ли отношение в НФБК, может быть сформулирован следующим образом:
Отношение находится в НФБК тогда и только тогда, когда каждый детерминант отношения является возможным ключом.
Таким образом, при декомпозиции отношений необходимо строить списки возможных ключей и детерминантов и сравнивать их на совпадение. Устранив таким образом большинство потенциальных аномалий, проектирование можно завершить.
Понятие о методах синтеза отношений
Исключить избыточность в исходном наборе ФЗ можно путем применения правил вывода ФЗ (См. учебный элемент "Функциональные зависимости"). Как известно, для класса F-зависимостей достаточно использовать шесть таких правил. При этом критерием останова процедуры исключения может служить получение минимального покрытия исходного набора ФЗ.Неединственность минимальных покрытий указывает на то, что порядок исключения избыточных ФЗ может оказать влияние на полученные результаты. Отсюда следует эмпирическое правило:
Избыточные ФЗ следует удалять по одной, каждый раз проводя анализ полученного набора ФЗ на избыточность.
В заключение изучения алгоритмов, основанных на декомпозиции отношений, следует подчеркнуть два обстоятельства, первое из которых указывает на преимущество методов, основанных на синтезе отношений, а второе является недостатком обоих подходов.
Первое. Если универсальное отношение содержит большое количество атрибутов, например более трех десятков, то ручное проектирование становится трудоемким и может, с одной стороны, привести к большим временным затратам, а с другой стороны, породить недопустимое для практики число отношений в базе данных. Поэтому в данном случае следует подумать об автоматизации процесса проектирования, т.е. создать программу проектирования схем баз данных.
Второе. Процесс проектирования реляционных баз данных характеризуется сложной математической природой. Показано, что задача проектирования является NP-сложной задачей, т.е. невозможно построить универсальный алгоритм декомпозиции - алгоритм на "все случаи жизни", на выполнение которого затрачивалось бы время, меньшее экспоненциального времени с числом шагов, пропорциональным eN, где N - число атрибутов.
Кроме того, задача приведения исходных отношений к НФБК может оказаться невыполнимой. Такой факт имел место в практике проектирования. Поскольку НФБК может не существовать на заданном наборе ФЗ, то логичным было бы отказаться от требования приведения отношений базы данных к этой форме. Эта ситуация подкрепляется и теоретически: при любом заданном множестве F-зависимостей над схемой r БД можно построить схему БД в 3НФ.
Таким образом, ограничимся поиском 3НФ в ходе применения метода синтеза, при этом остаются проблемы, связанные с выполнением операций над данными.
Пример преобразования ER-диаграмм в отношения базы данных
Продемонстрируем применение метода декомпозиции (без потерь при естественном соединении) для создания логической модели и базы данных для поддержки деятельности небольшой консультационной фирмы. Фирма производит консалтинг и обучение своих постоянных клиентов; данные о клиентах, сохраняемые в базе данных, будут использоваться консультантами фирмы для проведения семинаров, практических занятий и консультаций.Первый шаг проектирования базы данных заключается в выявлении всех сущностей предметной области, их атрибутов и связей между атрибутами сущностей. Анализ сведений о предметной области данного примера позволяет определить следующие атрибуты универсального отношения и сделать заключение о наличии функциональных зависимостей (ФЗ) между ними:
.
.
.
.
.Полученное универсальное отношение назовем КОНСУЛЬТАНТ.
Рис. 7.2. Универсальное отношение КОНСУЛЬТАНТ
Перечислим ФЗ предметной области базы данных:
Рассмотрим детерминанты и возможные ключи отношения КОНСУЛЬТАНТ.
| Возможные ключи | Детерминанты |
| {Номер, Тема, Семестр} | {Номер, Тема, Семестр} |
| {Номер} | |
| {Телефон} | |
| {Адрес} |
Согласно критерию Кодда, поскольку не каждый детерминант в отношении есть возможный ключ, то отношение не находится в НФБК.
Выполним декомпозицию отношения КОНСУЛЬТАНТ R0 (Номер, Тема, Семестр, Фамилия, Адрес, Телефон, Рейтинг). Кандидатами на выполнение проекции являются следующие ФЗ:
Внимание! На практике существует неединственность представления отношений базы данных, обусловленная выбором ФЗ при разбиении отношений. Выбор ФЗ для выполнения проекции отношения - очень важный шаг в проектировании логической модели реляционной базы данных. Выбор альтернативных ФЗ для выполнения проекции может привести к различным базам данных!
Выберем ФЗ
, тогда получим два отношения R1 (Номер, Тема, Семестр, Фамилия, Адрес, Рейтинг) и R2 (Адрес, Телефон). Первая итерация декомпозиции отношений представлена на рис. 7.3.
Рис. 7.3. Первая итерация декомпозиции отношений
Проверим, находится ли отношение R2 в НФБК.
Отношение R2 находится в НФБК.
Проверим, находится ли отношение R1 в НФБК.
| Возможные ключи | Детерминанты |
| {Номер, Тема, Семестр} | {Номер, Тема, Семестр} |
| {Номер} | |
| {Адрес} |
Отношение R1 не находится в НФБД, необходимо продолжить его декомпозицию. Выберем ФЗ
и выполним разбиение R1 на R3(Номер, Тема, Семестр, Рейтинг) и R4 (Номер, Фамилия, Адрес). Вторая итерация декомпозиции отношений представлена на рис. 7.4.
Рис. 7.4. Вторая итерация декомпозиции отношений
Проверим, находится ли отношение R3 в НФБК.
| Возможные ключи | Детерминанты |
| {Номер, Тема, Семестр} | {Номер, Тема, Семестр} |
Отношение R3 находится в НФБК.
Проверим, находится ли отношение R4 в НФБК.
| Возможные ключи | Детерминанты |
| {Номер} | {Номер} |
Отношение R4 находится в НФБК. Декомпозиция закончена.
Заметим, что если бы изначально в нашем примере в качестве ФЗ для выполнения проекции была выбрана ФЗ
, то в результате мы имели бы совсем другой (!) набор отношений.Литература: [1], [11], [15], [20], [31], [43], [44], [45].
Универсальное отношение
Рассмотрим пример отношения, содержащего данные о студенте университета Иванове (таблица 7.1).| 1000 | Иванов | Математика | /4 | 417 | 51-11 | |
| Компиляторы | Системное программирование | 5/4 | ||||
| Физика | /5 | |||||
| Окисление серы | Химия | 5/5 |
Пример. Универсальное отношение.
Видно, что данные содержат множественные поля, т.е. атрибуты неатомарны. Дублирование данных в атрибутах позволяет представить данные о студенте в форме отношения (таблица 7.2).
| 1000 | Иванов | Нет | Математика | /4 | 417 | 51-11 |
| 1000 | Иванов | Компиляторы | Системное программирование | 5/4 | 417 | 51-11 |
| 1000 | Иванов | Нет | Физика | /5 | 417 | 51-11 |
| 1000 | Иванов | Окисление серы | Химия | 5/5 | 417 | 51-11 |
Если в отношение включены все атрибуты из предметной области базы данных, то его называют универсальным отношением. Универсальное отношение находится в 1НФ. Как известно, отношением в 1НФ порождается множество аномалий в обработке данных (обновление, удаление, добавление, избыточность). Для того чтобы поместить универсальное отношение в базу данных, его необходимо нормализовать - разбить на совокупность более мелких отношений. При этом возникают следующие три вопроса:
Анализ аномалий в обработке данных показывает, что решение двух первых вопросов тесно связано с определением первичного ключа, распознавания явлений дублирования и избыточности, дублирования и неизбыточности данных. В основе всех этих явлений лежит концепция ФЗ. С практической точки зрения смысл ФЗ заключается в следующем: если имеет место
, то каждый из кортежей, имеющих одно и то же значение А, должен иметь одно и то же значение В. Изменение значений А и В во времени не должно нарушать ФЗ.Как же распознать ФЗ на практике? ФЗ определяется в каждой конкретной ситуации посредством детального анализа свойств всех атрибутов отношения и формирования заключения о типах их соотношений друг с другом. ФЗ не могут быть выявлены путем просмотра отдельного экземпляра отношения и нахождения двух атрибутов, имеющих одинаковые значения в разных кортежах. ФЗ должны быть получены из собственных свойств атрибутов предметной области базы данных. Просмотр отношения - это формальное определение возможных, но не действительных функциональных связей.
Определив все ФЗ, присущие предметной области базы данных, можно приступать к процессу разбиения отношений, именуемому декомпозицией схем отношений. Декомпозиция схем отношений является одним из основных методов построения логических моделей реляционных баз данных. Использование универсального отношения позволяет иметь отправную точку декомпозиции отношений базы данных. Результатом декомпозиции является нормализованная модель данных.
Основы проектирования реляционных баз данных
Арифметические функции
SQL поддерживает полный набор арифметических операций и математических функций для построения арифметических выражений над колонками базы данных (+, -, *, /, ABS, LN, SQRT и т.д.). Список основных встроенных математических функций дан ниже в таблице 8.2.| ABS(X) | Возвращает абсолютное значение числа Х |
| ACOS(X) | Возвращает арккосинус числа Х |
| ASIN(X) | Возвращает арксинус числа Х |
| ATAN(X) | Возвращает арктангенс числа Х |
| COS(X) | Возвращает косинус числа Х |
| EXP(X) | Возвращает экспоненту числа Х |
| SIGN(X) | Возвращает -1, если Х<0,0, если Х=0, +1, если Х>0 |
| LN(X) | Возвращает натуральный логарифм числа Х |
| MOD(X,Y) | Возвращает остаток от деления Х на Y |
| CEIL(X) | Возвращает наименьшее целое, большее или равное Х |
| ROUND(X,n) | Округляет число Х до числа с n знаками после десятичной точки |
| SIN(X) | Возвращает синус числа Х |
| SQRT(X) | Возвращает квадратный корень числа Х |
| TAN(X) | Возвращает тангенс числа Х |
| FLOOR(X) | Возвращает наибольшее целоеб меньшее или равное Х |
| LOG(a,X) | Возвращает логарифм числа Х по основанию А |
| SINH(X) | Возвращает гиперболический синус числа Х |
| COSH(X) | Возвращает гиперболический косинус числа Х |
| TANH(X) | Возвращает гиперболический тангенс числа Х |
| TRANC(X,n) | Усекает число Х до числа с n знаками после десятичной точки |
| POWER(A,X) | Возвращает значение А, возведенное в степень Х |
Набор встроенных функций может изменяться в зависимости от версии СУБД одного производителя и также в СУБД различных производителей. Так, например, в СУБД SQLBase, Centure Inc. есть функция @ATAN2(X,Y), которая возвращает арктангенс Y/X, но отсутствует функция SIGN(X).
Арифметические выражения необходимы для получения данных, которые непосредственно не сохраняются в колонках таблиц базы данных, но значения которых необходимы пользователю. Допустим, что вам необходим список служащих, показывающий выплату, которую получил каждый служащий с учетом премий и штрафов.
SELECT ENAME, SAL, COMM, FINE, SAL + COMM - FINE FROM EMPLOYEE ORDER BY DEPNO;
Арифметическое выражение SAL + COMM - FINE выводится как новая колонка в результирующей таблице, которая вычисляется в результате выполнения запроса. Такие колонки называют еще производными (вычисляемыми) атрибутами или полями.
Домены и допустимые типы данных
В информационной модели, создаваемой на этапе анализа, среда реализации не учитывается. Аналитик просто определяет атрибуты как строку, число или дату, в идеале он также назначает атрибуту домен. В контексте аналитика домен - это просто тип атрибута, например деньги или рабочий день. Аналитик может включить ряд проверок допустимости или правил обработки, например требование, что значение должно быть положительным, ненулевым и иметь максимум два десятичных разряда (это полезно для сумм долларовых трат, выставляемых банком на другой банк). Использование доменов аналитиком упрощает задачу обеспечения непротиворечивости. При переходе к проектированию физической модели проектировщику необходимо знать возможности выбранной СУБД по назначению типов данных колонок. В логической модели данных значения, которые может принимать атрибут отношения, также задаются доменом, который наследуется из информационной модели. В физической модели базы данных требуется, чтобы каждый атрибут отношения в базе данных обладал рядом свойств, которые диктуют, что в нем может храниться и что не может. Этими свойствами являются тип, размер и ограничения, которые могут еще более ограничивать допустимый набор значений столбца. Задача состоит в преобразовании домена в подходящий тип данных, поддерживаемый СУБД. Таким образом, проектировщик базы данных должен знать, какими типами данных он располагает при решении вышеуказанной задачи.В контексте проектирования физической модели реляционной базы данных домен - это выражение, определяющее разрешенные значения для колонок (атрибутов) отношения. При описании таблицы реляционной базы данных каждой колонке назначается определенный тип данных. Практически основу определения домена составляет тип данных, содержащихся в колонке, поскольку большинство встроенных типов задают разрешенный интервал значений данных.
Пример. Колонку в базе данных можно описать следующим образом:
amount NUMBER (8,2) NOT NULL CONSTRAINT cc_limit_amnt CHECK (amount > 0)
В этой колонке можно размещать только числовые данные; она должна быть заполнена для каждой таблицы; ее значение должно быть положительным; точность этого значения - два значащих десятичных разряда. Максимальное значение, которое может храниться в этом столбце, - 999999.99. В этом простом определении колонки мы фактически определили ряд неявных правил, проверку которых Oracle принудительно включает при вводе данных в базу данных.
Как видно, дальнейшее определение домена колонки (после присвоения ей типа) выполняется проектировщиком с помощью уточнений правил изменения значений. Такие уточнения поддерживаются в SQL с помощью механизма ограничений в спецификации колонки в таблице (см. далее). В этом разделе мы рассмотрим связь между понятием домена и допустимыми в СУБД типами данных.
В стандарт SQL-92 введено понятие доменов, определенных пользователем. Определение таких доменов базируется на встроенных типах данных СУБД.
Допустимые типы данных
Все допустимые типы данных описаны в стандарте SQL-92, но в большинстве диалектов поддерживается расширенный список типов данных. Однако любой диалект SQL поддерживают три общих типа данных: строковые, числовые и тип для представления даты и времени. Задание типа данных определяет значения и длину данных, а также формат их представления при визуализации.Для всех типов данных определено так называемое нуль-значение, которое указывает на отсутствие данных в колонке указанного типа, т.е. то обстоятельство, что значение данных в текущий момент времени неизвестно.
Описание типов, данное в таблице ниже, относится к диалекту SQL для СУБД SQLBase, которое имеет существенные отличия от предписаний стандарта SQL. В комментарии уточняются сведения о типах данных, принятые в реализации СУБД Oracle. Жирным шрифтом выделена часть зарезервированного слова для определения типа, которую можно использовать как аббревиатуру при определении типа в спецификации колонки.
Данные строкового типа представляют собой последовательность строк символов. Строковые данные могут быть заданы как с предопределенной длиной (ключевые слова char или varchar (длина строки)), так и без указания длины (ключевое слово long varchar) для представления строк произвольной длины. Тип данных varchar2 определяет строку символов переменной длины, имеющую максимальный размер size. В отличие от строкового типа с предопределенной длиной, со строками long varchar не допускаются операции сравнения, и они не могут быть использованы в выражениях и как аргументы большинства встроенных функций. В Oracle этот тип не может быть использован в определении последовательности. Строки последнего типа могут применяться для сохранения битовых образов. Стандарт SQL-92 не имеет типа long varchar и varchar.
Обратим внимание на тип данных varchar2. Он, так же как и тип данных char, предназначен для представления алфавитно-цифровых данных. Но он имеет формат переменной длины. Последнее означает, что длина колонки такого типа равна числу символов в ней, в то время как колонка типа char использует все определенное для нее пространство.
Сравним две колонки с содержанием 'abc', но с типами varchar2(5) и char(5). Первая занимает действительно 3 байта, а вторая - 5 байт. Оставшиеся два байта заполняются символом "white space", который аналогичен пропуску, возникающему при нажатии на клавиатуре клавиши space bar. Несмотря на то, что колонки содержат одинаковые строки, они не равны, так как первая в 4-й и 5-й позициях содержат null-значение, а вторая в тех же позициях содержит white space. Это может привести к проблемам при соединении таблиц по таким колонкам. Обычно колонки типа varchar2 не планируются для использования в процедурах поиска данных в базе данных. В них хранят текст.
Существует два типа числовых данных.
Числовые типы данных предназначены для представления целых чисел, чисел с десятичной точкой и чисел с плавающей точкой. Любое представление чисел задается своей точностью и масштабом. Точность определяет допустимое представлением количество значащих цифр числа, а масштаб - количество значащих цифр после десятичной точки.
Для представления целых чисел используются типы interger (точность 10 значащих цифр) и smallint (точность 5 значащих цифр).
Для представления чисел с фиксированной десятичной точкой используются типы number (точность, масштаб) (для чисел с точностью до 15 значащих цифр) и decimal (точность, масштаб) (для чисел заданной точности до 15 значащих цифр). Если указать для колонки тип number без задания масштаба, максимальное число значащих цифр для Oracle будет 105. Вместо задания точности и масштаба может быть указан символ *. Это будет эквивалентно заданию просто типа number. Различие между этими типами данных состоит в том, что для типа number нет необходимости следить за точностью при выполнении операций.
При выполнении операций с числами этих типов действуют следующие формулы для определения точности и масштаба результата (p - точность, s - масштаб):
сложение/вычитание точность=max{min[15, max(p1-s1, p2-s2)+max(s1, s2)+1]} масштаб=max[s1, s2] деление точность=15 масштаб=15-p1+s1-s2 умножение точность=min{15, p1+p2} масштаб=min{15, s1+s2}
Для представления чисел с плавающей точкой в SQL предусмотрены следующие типы данных:
Тип данных для представления даты и времени отсутствует в стандарте SQL. Обычно в конкретных диалектах SQL используются три типа для представления таких данных:
В СУБД Oracle тип date принимает допустимые значения от 1 января 4712 ВС до 31 декабря 4712 АD. Формат по умолчанию - "ДД-МММ-ГГ".
В СУБД Oracle представлен набор типов данных для хранения объектов большого размера: Long Raw для хранения очень больших по размеру данных цифровой природы и raw для хранения битовых строк сравнительно небольшого размера.
В Oracle есть еще два типа данных для представления метки безопасности операционной системы (secure operating system label): msllabel в виде четырех последовательных байт и raw msllabel - в двоичном формате.
Правила преобразования типов представлены в таблице 8.9 ниже.
| Строковый | Числовой | Значение исходного типа должно быть в форме допустимой для числовых значений |
| Числовой | Строковой | Нет необходимости в одинарных кавычках |
| Дата/время | Числовой | |
| Числовой | Дата/время | |
| Дата/время | Строковой | Нет необходимости в одинарных кавычках |
| Строкой | Дата/время | Значение исходного типа должно быть в форме допустимой для значений даты и время |
Функции для обработки даты
В диалекте SQL СУБД Oracle имеется небольшой набор функций для манипулирования колонками с типом date. Список основных функций обработки даты и времени приведен в таблице 8.6.| SYSDATE | Возвращает текущую дату и время |
| ROUND(D[,F]) | Округляет значение даты D согласно заданному шаблону |
| TRANC(D[,F]) | Усекает значение даты D согласно заданному шаблону |
| NEXT_DAY(D,S) | Возвращает дату дня, который является первым днем, более поздним, чем текущая дата с названием S |
Если вам потребовался список новых служащих, поступивших за последний квартал в организацию, то вы можете написать запрос в следующем виде:
SELECT ENAME, HIREDATE, HIREDATE + 92 DAYS FROM EMPLOYEE WHERE HIREDATE + 92 DAYS > SYSDATE AND DEPNO=30;
Ключевое слово SYSDATE всегда возвращает текущую дату. В этом примере также показано, как используется арифметический оператор сложения с переменными типа "дата". К переменной типа "дата" можно прибавлять и вычитать из него целое число дней, месяцев, лет, часов, минут, секунд, микросекунд. Для этого используются соответствующие ключевые слова (DAY, MONTH и т.д.), следующие за целой константой (дробная часть игнорируется, если вы указываете число с десятичной точкой). Имеется ограничение на использование скобок в таких выражениях (так, заключение в скобки выражения 1 DAYS + 1 YEARS приведет к ошибке).
Функции обработки строк
SQL предоставляет вам широкий набор функций для манипулирования со строковыми данными (конкатенация строк, CHR, LENGTH, INSTR и другие). Список основных функций для обработки строковых данных приведен в таблице 8.3.| CHR(N) | Возвращает символ ASCII кода для десятичного кода N |
| ASCII(S) | Возвращает десятичный ASCII код первого символа строки |
| INSTR(S2.S1.pos[,N] | Возвращает позицию строки S1 в строке S2 большую или равную pos.N - число вхождений |
| LENGHT(S) | Возвращает длину строки |
| LOWER(S) | Заменяет все символы строки на прописные символы |
| INITCAP(S) | Устанавливает первый символ каждого слова в строке на заглавный, а остальные символы каждого слова - на прописные |
| SUBSTR(S,pos,[,len]) | Выделяетв строке S подстроку длиной len, начиная с позиции pos |
| UPPER(S) | Преобразует прописные букцвы в строке на заглавные буквы |
| LPAD(S,N[,A]) | Возвращает строку S, дополненную слева симолами A до числа символов N. Символ - наполнитель по умолчанию - пробел |
| Rpad(S,N[,A]) | Возвращает строку S, дополненную справа симолами A до числа символов N. Символ - наполнитель по умолчанию - пробел |
| LTRIM(S,[S1]) | Возвращает усеченную слева строку S. Символы удаляются до тех пор, пока удаляемый символ входит в строку - шаблон S1 (по умолчанию - пробел) |
| RTRIM(S,[S1]) | Возвращает усеченную справа строку S. Символы удаляются до тех пор, пока удаляемый символ входит в строку - шаблон S1 (по умолчанию - пробел |
| TRANSLATE(S,S1,S2) | Возвращает строку S, в которой все вхождения строки S1 замещены строкой S2. Если S1 <> S2, то символы, которым нет соответствия, исключаются из результирующей строки |
| REPLACE(S,S1,[,S2]) | Возвращает строку S, для которой все вхождения строки S1 замещены на подстроку S2. Если S2 не указано, то все вхождения подстроки S1 удаляются из результирующей строки |
| NVL(X,Y) | Если Х есть NULL, то возвращает в Y либо строку, либо число, либо дату в зависимости от исходного типа Y |
Названия одних и тех же функций могут отличаться в различных СУБД.
Так, например, функция СУБД Oracle SUBSTR(S, pos, [, len]) в СУБД SQLBase называется @SUBSTRING(S, pos, len). В СУБД SQLBase имеются функции, которых нет в СУБД Oracle (см. таблицу ниже, где приведен список таких функций).
| @EXACT(S1,S2) | Возвращает результат сравнения двух строк |
| @LEFT(S,len) | Возвращает левую подстроку длиной len |
| LENGTH(S) | Возвращает длину строки |
| @MID(S, pos, len) | Возвращает подстроку указанной длины, начиная с позиции pos |
| @REPEAT(S,n) | Повторяет строку S n раз |
| @REPLACE(S1,pos,len,S2) | Замещает с позиции pos len символов в строке S2 символами строки S1 |
| RIGHT(S,len) | Возвращает правую подстроку S длиной len |
| @SCAN(S,pat) | Возвращает позицию подстроки pat в строке S |
| @STRING(X,scale) | Возвращает символьное представление числа с указанным масштабом scale |
| @TRIM(S) | Удаляет пробелы в строке справа и слева |
| @VALUE(S) | Преобразует символьное представление числа в числовое значение |
SELECT INITCAP(ENAME) FROM EMPLOYEE ORDER BY DEPNO;
Иерархия объектов реляционной базы данных
Одной из главных задач, которые обязан решить проектировщик на стадии проектирования физической модели реляционной базы данных, является задача превращения объектов логической модели реляционной базы данных в объекты реляционной базы данных. Для решения этой задачи проектировщику базы данных необходимо знать: а) какими объектами располагает реляционная база данных в принципе; б) какие объекты поддерживает конкретная СУБД, которая выбрана для реализации базы данных.Таким образом, мы предполагаем, что решение о выборе СУБД уже принято руководителем ИТ-проекта, и согласовано с заказчиком базы данных, т.е. СУБД задана. Проектировщик базы данных должен ознакомиться с документацией, в которой описан диалект SQL, поддерживаемый выбранной СУБД. В настоящей лекции предполагается, что была выбрана СУБД Oracle 9i, хотя подавляющая часть материала охватывает объекты в любой промышленной реляционной СУБД.
Замечание. О выборе СУБД. Выбор СУБД относится к многокритериальной задаче выбора и в настоящем курсе не рассматривается. Следует помнить о том, что СУБД обычно поддерживает только одну модель данных: реляционную, иерархическую, сетевую, многомерную, объектно-ориентированную, объектно-реляционную. Исключение составляют небольшое число СУБД. Например, ADABAS, Software AG (сетевая и реляционная модели), или Oracle 9i, Oracle Inc. (реляционная и объектно-реляционная модели). Обычно при выборе СУБД при всех прочих равных возможностях стараются создать базу данных на СУБД, претендующей на промышленный стандарт.
Иерархия объектов реляционной базы данных прописана в стандартах по SQL, в частности, в стандарте SQL-92, на который мы будем ориентироваться при изложении материала настоящей лекции. Этот стандарт поддерживается практически всеми современными СУБД, вплоть до настольных. Иерархия объектов реляционной базы данных показана на рисунке ниже.
На самом нижнем уровне находятся наименьшие объекты, с которыми работает реляционная база данных, - столбцы (колонки) и строки. Они, в свою очередь, группируются в таблицы и представления.
Замечание. В контексте лекции атрибуты, колонки, столбцы и поля считаются синонимами. То же относится и к терминам "строка", "запись" и "кортеж".
Таблицы и представления, которые представляют физическое отражение логической структуры базы данных, собираются в схему. Несколько схем собираются в каталоги, которые затем могут быть сгруппированы в кластеры. Следует отметить, что ни одна из групп объектов стандарта SQL-92 не связана со структурами физического хранения информации в памяти компьютеров.
Рис. 8.1. Иерархия объектов реляционной базы данных, соответствующая стандарту SQL-92
Помимо указанных на рисунке объектов, в реляционной базе данных могут быть созданы индексы, триггеры, события, хранимые команды, хранимые процедуры и ряд других. Теперь перейдем к определению объектов реляционной базы данных.
Использование агрегатных функций в запросах
Агрегатные функции в SQL позволяют выбирать обобщающую информацию из группы строк и проводить систематизацию данных. Список агрегатных функций приведен в таблице 8.7. Агрегатные функции почти во всех реализациях SQL носят одинаковые имена. Различие в наименование для Oracle дано через косую черту.| AVG(X) = AVG(ALL X) AVG(DISTINCT X) | Вычисляет среднее значение аргумента, который может быть выражением любого типа. Нуль-значения игнорируются, ключевое слово DISTINCT подавляет дубликаты |
| COUNT(*) COUNT(X) = COUNT(ALL X) COUNT(DISTINCT X) | Вычисляет числа итемов. При указании * всегда возвращается число строк в таблице. Указание DISTINCT подавляет дуюликаты |
| MAX(X) = MAX(ALL X) MAX (DISTINCT X) | Вычисляет максимальное значение аргумента, который может быть выражением любого типа. Нуль-значения игнорируются, ключевое слово DISTINCT подавляет дубликаты |
| MIN(X) = MIN(ALL X) MIN (DISTINCT X) | Вычисляет минимальное значение аргумента, который может быть выражением любого типа. Нуль-значения игнорируются, ключевое слово DISTINCT подавляет дубликаты |
| SUM(X) = SUM(ALL X) SUM (DISTINCT X) | Вычисляет сумму значение аргумента, который может быть выражением любого типа. Нуль-значения игнорируются, ключевое слово DISTINCT подавляет дубликаты |
| STDDEV([DISTINCT|ALL]X) | Вычисляет стандартное отклонение на множестве значений аргумента, который может быть выражением любого типа. Нуль-значения игнорируются, ключевое слово DISTINCT подавляет дубликаты |
| VARIANCE([DISTINCT|ALL]) | Вычисляет квадрат дисперсии |
Использование функций агрегирования позволяет вам находить суммарные значения колонок и разброс данных в колонке. Так, после выполнения запроса
SELECT SUM(SAL) FROM EMPLOYEE;
вы узнаете итоговую сумму зарплаты по организации, а из запроса
SELECT AVG(SAL), STDDEV(SAL) FROM EMPLOYEE;
- среднюю зарплату по организации и ее разброс (дисперсию).
Однако наиболее часто требуется подобная итоговая информация не для таблицы в целом, а для определенных наборов (групп) строк таблицы.
Для того чтобы группировать строки таблицы по какому-либо признаку, в команде SELECT существует специальное предложение GROUP BY, которое задает колонку (или колонки) для проведения группировки. Это предложение группирует строки таблицы по значениям колонок группировки с последующим подавлением дублирующих значений в колонках группировки, т.е. позволяет определять подмножество значений некоторой колонки в терминах другой колонки и применять к полученным подмножествам функции агрегирования.
Предположим, что вы хотите найти минимальные и максимальные оклады служащих в подразделениях, тогда вы можете написать
SELECT DEPNO, MIN(SAL), MAX(SAL) FROM EMPLOYEE GROUP BY DEPNO;
Предложение GROUP BY должно следовать после предложения WHERE, если последнее присутствует в команде SELECT. Каждая строка результирующей таблицы относится к одной группе строк. Число групп определяется числом различных значений в колонке группировки (в данном случае DEPNO). Агрегатные функции применяются к каждой группе как к отдельному множеству.
Агрегатные функции можно использовать при соединении таблиц. Допустим, что вам нужно знать, сколько служащих работает на каждой должности в каждом подразделении, какова сумма зарплаты на подразделение и средняя зарплата. Тогда вам нужен запрос
SELECT DNAME, JOB, SUM(SAL), COUNT(*), AVG(SAL) FROM EMPLOYEE, DEPARTAMENT WHERE EMPLOYEE.DEPNO=DEPARTAMENT.DEPNO GROUP BY DNAME, JOB;
Функции SUM( ), COUNT( ), AVG( ) вычисляют суммы, число строк в группе и среднее значение в группе строк.
В SQL можно задавать условия поиска для группы строк. Для этого в команде SELECT существует предложение HAVING, которое должно следовать за предложением GROUP BY. HAVING задает условие поиска для группы строк.
Допустим, что вам необходимо получить ответ на тот же вопрос, что и в предыдущем примере, но при этом каждая группа должна состоять не менее чем из двух сотрудников.
SELECT DNAME, JOB, SUM(SAL), AVG(SAL) FROM EMPLOYEE, DEPARTAMENT WHERE EMPLOYEE.DEPNO=DEPARTAMENT.DEPNO GROUP BY DNAME, JOB HAVING COUNT(*)>=2;
Условие поиска в предложении HAVING исключает из результирующей таблицы группы, содержащие менее двух работников.
Таким образом, вы познакомились с различными вариантами использования команды SQL SELECT.
Константы, выражения, системные переменные
Константы обычно специфицируют единственное значение и, в соответствии с типом представляемых данных, могут быть строковыми, числовыми и представлять дату/время. Строковые константы должны быть заключены в одинарные кавычки.В SQL существует ряд предопределенных системных переменных, которые можно использовать в выражениях вместо имен колонок и констант. К таким переменным относятся следующие:
Выражением в SQL является итем или комбинация итемов с допустимыми для них операциями, которая дает единственное значение. В качестве итемов могут выступать имена колонок, константы, связанные переменные, результаты вычислений функций, системные переменные и другие выражения. При этом если один из итемов имеет нуль-значение, то результат выражения также имеет нуль-значение.
В этом разделе вы узнали, какие вcтроенные типы данных предоставляются проектировщику баз данных в диалектах SQL доменов в физической модели реляционной базы данных. Заметим, что наиболее распространены три из них - varchar2, number и date. Наличие такого небольшого набора типов данных может показаться недостатком, однако это не так. В Oracle типы, определенные в других СУБД и диалектах SQL, можно создать, используя определенный пользователем тип данных. Например, тип money - это тип number с двумя десятичными разрядами, а тип positive integer - тип number без десятичных разрядов и с ограничением на ввод отрицательных значений. По крайней мере, при таком положении дел вам не приходится беспокоиться об ограничениях на внутреннюю память, решая, как хранить вещественное число - с использованием типа float или типа double.
Самое главное при выборе типов данных - обеспечение непротиворечивости. Если вы определите номер шасси автомобиля в одной таблице как number(11), а в другой таблице - как varchar(15), то, когда дело дойдет до соединения этих таблиц, неприятности вам обеспечены. Напишите-ка SQL-предложение для сравнения 918273645 и "918-27-36/4/5". Да так, чтобы оно эффективно работало в предложении, выполняющем соединение!
Описание основных операторов SQL
SQL состоит из набора команд манипулирования данными в реляционной базе данных, которые позволяют создавать объекты реляционной базы данных, модифицировать данные в таблицах (вставлять, удалять, исправлять), изменять схемы отношений базы данных, выполнять вычисления над данными, делать выборки из базы данных, поддерживать безопасность и целостность данных.Весь набор команд SQL можно разбить на следующие группы:
При выполнении каждая команда SQL проходит четыре фазы обработки:
В настоящее время оптимизатор является составной частью любой промышленной реализации SQL. Работа оптимизатора основана на сборе статистики о выполняемых командах и выполнении эквивалентных алгебраических преобразований с отношениями базы данных. Такая статистика сохраняется в системном каталоге базы данных. Системный каталог является словарем данных для каждой базы данных и содержит информацию о таблицах, представлениях, индексах, колонках, пользователях и их привилегиях доступа. Каждая база данных имеет свой системный каталог, который представляет совокупность предопределенных таблиц базы данных.
Таблица 8.1 содержит список команд SQL в соответствии с принятым стандартом, за исключением некоторых практически не используемых в диалектах команд.
Жирным шрифтом выделены команды диалекта SQL СУБД Oracle.
| Команды определения данных объектов | |
| ALTER TABLE | Изменяет описание таблицы (схему отношения) |
| CREATE EVENT | Создает событие таймера в базе данных |
| CREATE INDEX | Создает индекс для таблицы |
| CREATE SEQUENCE | Создает последовательность |
| CREATE TABLE | Определяет таблицу |
| CREATE TABLESPACE | Создает табличное пространство |
| CREATE TRIGGER | Создает триггер в базе данных |
| CREATE VIEW | Определяет представление на таблицах |
| DROP INDEX | Физически удаляет индекс из баз данных |
| DROP SEQUENCE | Удаляет последовательность |
| DROP TABLE | Физически удаляет таблицу из базы данных |
| DROP TABLESPACE | Удаляет табличное пространство |
| DROP VIEW | Удаляет представление |
| Команды манипулирвания данными | |
| DELETE | Удаляет одну или более строк из таблицы базы данных |
| INSERT | Вставляет одну или более строк в таблицу баззы данных |
| UPDATE | Обновляет значения колонок в таблице базыы данных |
| Команды выборки данных | |
| SELECT | Выполняет запрос на выборку данных из таблиц и представлений |
| UNION | Объединяет в одной выборке результаты выполнения двух или более команд SELECT |
| Команды управления транзакциями | |
| COMMIT | Завершает транзакцию и физически актуалищирует состояние базы данных |
| ROLLBACK | Завершает транзакцию и возвращает текущее состояние базы данных на момент последней завершенной транзакции и контрольной точки |
| SAVEPOINT | Назначает контрольную точку внутри транзакции |
| Команды управления данными | |
| ALTER DATABASE | Изменяет группы хранения или журналы транзакций |
| ALTER DBAREA | Изменяет размер областей хранения базы данных |
| ALTER PASSWORD | Изменяет пароль для доступа к базе данных |
| ALTER STOGROUP | Изменяет состав областей хранения в группе хранения |
| CHECK DATABASE | Проверяет целостность базы данных |
| CHECK INDEX | Проверяет целостность индекса |
| CHECK TABLE | Проверяет целостность таблицы и индекса |
| CREATE DATABASE | Физически создает базу данных |
| CREATE DBAREA | Создает область хранения базы данных |
| CREATE STOGROUP | Создает группу хранения |
| CREATE SYSNONYM | Создает синоним для таблицы или представления |
| DEINSTALL DATABASE | Делает базу данныхх недоступной пользователям вфычислительной сети |
| DROP DATABASE | Физически удаляет базы данных |
| DROP DBAREA | Физически удаляет область хранения данных |
| DROP STOGROUP | Удаляет группу хранения |
| GRANT | Определяет привелеги пользователей и разграничение доступа к базе данных |
| INSTALL DATABASE | Делает базу данных доступной пользователям вычислительной сети |
| LOCK DATABASE | Блокирует текущую активную базу данных |
| REVOKE | Отменяет привелегии пользователей и разграничения доступа к базе данных |
| SET DEFAULT STOGROUP | Определяет группу хранения по умолчанию |
| UNLOCK DATABASE | Деблокирует текущую активную базу данных |
| UPDATE STATISTIK | Обновляет статистику для базы данных |
| Другие команды | |
| COMMENT ON | Размещает в системном каталоге комментарии к описанию объектов БД |
| CREATE SYNONYM | Определяет в системном каталоге альтернативные имена для таблиц и представлений БД |
| DROP SYNONYM | Удаляет из системного каталого альтернативные именя для таблиц и представлений БД |
| LABEL | Изменяет метки системных описаний |
| ROWCOUNT | Вычисляет число строк в таблице БД |
Набор команд SQL, перечисленный в таблице, не является полным. Этот список приведен, чтобы вы составили впечатление о возможностях SQL в целом. Для получения полного списка команд следует обратиться к соответствующему руководству для конкретной СУБД. Следует помнить, что SQL является единственным средством общения всех категорий пользователей с реляционными базами данных.
Основные объекты реляционной базы данных
Кластеры, каталоги и схемы не являются обязательными элементами стандарта и, следовательно, программной среды реляционных баз данных.Под кластером понимается группа каталогов, к которым можно обращаться через одно соединение с сервером базы данных (программная компонента СУБД).
На практике процедура создания каталога определяется реализацией СУБД на конкретной операционной платформе. Под каталогом понимается группа схем. На практике каталог часто ассоциируется с физической базой данных как набором физических файлов операционной системы, которые идентифицируются ее именем.
Для проектировщика базы данных схема - это общее логическое представление отношений законченной базы данных. С точки зрения SQL, схема - это контейнер для таблиц, представлений и других структурных элементов реляционной базы данных. Принцип размещения элементов базы данных в каждой схеме полностью определяется проектировщиком базы данных.
Для создания таблиц и представлений наличие схемы не обязательно. Если у вас планируется инсталляция только одной логической базы данных, то ясно, что можно обойтись и без схемы. Но если планируется, что одна и та же СУБД будет использоваться для поддержки нескольких баз данных, то надлежащая организация объектов баз данных в схемы может значительно облегчить сопровождение этих баз данных. На практике схема часто ассоциируется с объектами определенного пользователя физической базы данных.
Далее объекты реляционной базы данных будут вводиться в контексте реляционной СУБД Oracle 9i. Такой подход принят потому, что проектирование физической модели реляционной базы данных выполняется для конкретной среды ее реализации.
В Oracle 9i термин схема (Schema) используется для описания всех объектов базы данных, которые созданы некоторым пользователем. Для каждого нового пользователя автоматически создается новая схема.
К числу основных объектов реляционных баз данных относятся таблица, представление и пользователь.
Таблица (Table) является базовой структурой реляционной базы данных.
Она представляет собой единицу хранения данных - отношение. Таблица идентифицируется в базе данных своим уникальным именем, которое включает в себя идентификацию пользователя. Таблица может быть пустой или состоять из набора строк.
Представление (View) - это поименованная динамически поддерживаемая СУБД выборка из одной или нескольких таблиц базы данных. Оператор выборки ограничивает видимые пользователем данные. Обычно СУБД гарантирует актуальность представления - его формирование производится каждый раз, когда представление используется. Иногда представления называют виртуальными таблицами.
Пользователь (User) - это объект, обладающий возможностью создавать или использовать другие объекты базы данных и запрашивать выполнение функций СУБД, таких как организация сеанса работы, изменение состояние базы данных и т. д.
Для упрощения идентификации и именования объектов в базе данных поддерживается такие объекты, как синоним, последовательность и определенные пользователем типы данных.
Синоним (Synonym) - это альтернативное имя объекта (псевдоним) реляционной базы данных, которое позволяет иметь доступ к данному объекту. Синоним может быть общим и частным. Общий синоним позволяет всем пользователям базы данных обращаться к соответствующему объекту по его псевдониму. Синоним позволяет скрыть от конечных пользователей полную квалификацию объекта в базе данных.
Последовательность (Sequence) - это объект базы данных, который позволяет генерировать последовательность уникальных чисел (номеров) в условиях многопользовательского асинхронного доступа. Обычно элементы последовательности используются для уникальной нумерации элементов таблиц (строк) в операциях модификации данных.
Определенные пользователем типы данных (User-defined data types) представляют собой определенные пользователем типы атрибутов (домены), которые отличаются от поддерживаемых (встроенных) СУБД типов. Они определяются на основе встроенных типов. Определенные пользователем типы данных образуют ту часть среды СУБД, которая организована в соответствии с объектно-ориентированной парадигмой.
Для обеспечения эффективного доступа к данным в реляционных СУБД поддерживаются ряд других объектов: индекс, табличная область, кластер, секция.
Индекс (Index) - это объект базы данных, создаваемый для повышения производительности выборки данных и контроля уникальности первичного ключа (если он задан для таблицы). Полностью индексные таблицы (index-organized tables) исполняют роль таблицы и индекса одновременно.
Табличное пространство или область (Tablespace) - это именованная часть базы данных, используемая для распределения памяти для таблиц и индексов. В Oracle 9i - это логическое имя физических файлов операционной системы. Все объекты базы данных, в которых хранятся данные, соответствуют некоторым табличным пространствам. Большинство объектов базы данных, в которых данные не хранятся, находятся в словаре данных, расположенном в табличном пространстве SYSTEM.
Кластер (Cluster) - это объект, задающий способ совместного хранения данных в нескольких или одной таблице. Одним из критериев использования кластера является наличие общих ключевых полей в нескольких таблицах, которые используются в одной и той же команде SQL. Обычно кластеризованные столбцы или таблицы хранятся в базе данных в виде таблиц хэширования (т.е. специальным образом).
Секция (Partition) - это объект базы данных, который позволяет представить объект с данными в виде совокупности подобъектов, отнесенных к различным табличным пространствам. Таким образом, секционирование позволяет распределять очень большие таблицы на нескольких жестких дисках.
Для обработки данных специальным образом или для реализации поддержки ссылочной целостности базы данных используются объекты: хранимая процедура, функция, команда, триггер, таймер и пакет (Oracle). С помощью этих объектов базы данных можно выполнять так называемую построчную обработку (record processing) данных. С точки зрения приложений баз данных построчная обработка - это последовательная выборка данных по одной строке, ее обработка и переход к обработке следующей строки.
Данные объекты реляционной базы данных представляют собой программы, т.е. исполняемый код. Этого код обычно называют серверным кодом (server-side code), поскольку он выполняется компьютером, на котором установлено ядро реляционной СУБД. Планирование и разработка такого кода является одной из задач проектировщика реляционной базы данных.
Хранимая процедура (Stored procedure) - это объект базы данных, представляющий поименованный набор команд SQL и/или операторов специализированных языков обработки программирования базы данных (например, SQLWindows или PL/SQL).
Функция (Function) - это объект базы данных, представляющий поименованный набор команд SQL и/или операторов специализированных языков обработки программирования базы данных, который при выполнении возвращает значение - результат вычислений.
Команда (Command) - это поименованный оператор SQL, который заранее откомпилирован и сохраняется в базе данных. Скорость обработки команды выше, чем у соответствующего ему оператора SQL, т.к. при этом не выполняются фазы синтаксического разбора и компиляции.
Триггер (Trigger) - это объект базы данных, который представляет собой специальную хранимую процедуру. Эта процедура запускается автоматически, когда происходит связанное с триггером событие (например, до вставки строки в таблицу).
Таймер (Timer) отличается от триггера тем, что запускающим событием для хранимой процедуры является событие таймера.
Пакет (Package) - это объект базы данных, который состоит из поименованного структурированного набора переменных, процедур и функций.
В распределенных реляционных СУБД имеются специальные объекты: снимок и связь базы данных.
Снимок (Snapshop) - локальная копия таблицы удаленной базы данных, которая используется для тиражирования (репликации) таблицы или результата запроса. Снимки могут быть модифицируемыми или предназначенными только для чтения.
Связь базы данных (Database Link) или связь с удаленной базой данных - это объект базы данных, который позволяет обратиться к объектам удаленной базы данных.Имя связи базы данных, грубо говоря, можно представить как ссылку на параметры доступа к удаленной базы данных.
Для эффективного управления разграничением доступа к данным в Oracle поддерживает объект роль.
Роль (Role) - объект базы данных, представляющий собой поименованную совокупность привилегий, которые могут назначаться пользователям, категориям пользователей или другим ролям.
Правила определения имен
Как и в любом языке, имена используются для идентификации элементов и объектов языка. В этом отношении имя есть идентификатор объекта SQL. Имена бывают длинными (до 18 символов) и короткими (до 8 символов). Также различают обыкновенный идентификатор, который начинается с буквы или символов #, @, $ и состоит из букв, цифр и символа _, и идентификатор в апострофах (Delimited Identifier), который состоит из произвольных символов, заключенных в двойные кавычки.Объекты SQL именуются в соответствии со своей иерархией, и могут иметь квалифицируемые имена, когда имя объекта квалифицируется именем охватывающего объекта, присоединенного к имени вложенного объекта через точку. По стандарту SQL охватывающим является имя схемы, которое есть практически во всех реализациях реляционных СУБД, в том числе и в Oracle. Нижеследующие объекты SQL должны иметь уникальное имя.
Имя команды определяется пользователем.
Таким образом, способ именования и идентификации объектов реляционной базы данных задается отчасти их иерархией и подчиняется следующим общим правилам:
Для предметной области базы данных
Для предметной области базы данных для иллюстративных примеров можно выделить следующие основные классы объектов: подразделения (схема структурной организации фирмы), сотрудники (штатное расписание) и подчиненные им объекты (дети, родственники, например), проекты, выполняемые данной организацией.Сотрудник как объект определяется карточкой личного учета, которая имеет весьма сложную внутреннюю структуру и которую целесообразно как теоретически, так и практически представлять совокупностью объектов, связанных в целое через ее номер (чаще всего искусственно придуманный табельный номер служащего). Аналогично, подразделение как объект определяется структурой организации и его функциями в ней. Проекты (другими словами, работы) являются объектами, которые отражают состояние деятельности организации в получении прибыли. Логическая схема базы данных приведена на рис. 8.2. Для простоты изложения большая часть атрибутов и объектов опущено - пример преследует иллюстрированные и учебные цели и не претендует на полноту представления данных.
Рис. 8.2. Логическая структура учебной базы данных
Определение таблиц данных приведено ниже. Таблица DEPARTAMENT содержит информацию о подразделениях организации, таблица EMPLOYEE - о служащих данной организации, таблица PROJECT - информацию о проектах, выполняемых в организации.
| Номер подразделения | DEPNO (PK) | Integer |
| Наименование | DNAME | char(20) |
| Размещение | LOC | char(20) |
| Руководитель | MANAGER | char(25) |
| Телефон | PHONE | CHAR(15) |
| Номер личной карточки |
| Номер личной карточки | EMPNO (PK) | Integer |
| Фамилия | ENAME | char(25) |
| Имя | LNAME | char(20) |
| Страховка | SSECNO | char(10) |
| Номер подразделения | DEPNO | Integer |
| Должность | JOB | char(25) |
| Возраст | AGE | Integer |
| Стаж | HIREDATE | Data |
| Доплаты | COMM | dec(9,2) |
| Зарплата | SAL | dec(9,2) |
| Штрафы | FINE | dec(9,2 |
| Шифр проекта | PROJNO | char(8) |
| Наименование | PNAME | char(25) |
| Стоимость | BUDGET | Number(9,2) |
Специальные функции
SQL обеспечивает набор специальных функций для преобразований значений колонок. Список таких функций приведен в таблице 8.5.| DECODE(E,S1,R1,S2,R2,…,[def]) | Если E соответствует Si, то возвращается Ri, в противном случае - def или NULL, если умолчание не задано |
| TO_NUMBER(S) | Возвращает результат преобразования строки S в аргумент типа NUMBER |
| TO_CHAR(X[,F]) | Возвращает результат преобразования строки S в аргумент типа DATE согласно заданному формату даты F |
| TO_DATE(S[,F]) | Возвращает результат преобразования значения параметра S символьного типа в тип DATE |
В таблице EMPLOYEE для каждого служащего можно ввести признак пола - добавить колонку SEX типа CHAR(1) (0 - мужской, 1 - женский). Допустим, что вам нужен список служащих, в котором требуется разделение их по признаку пола с указанием его в числовом формате; тогда можно задать такую команду:
SELECT ENAME, LNAME, AGE, 'Пол:', TO_NUMBER(SEX) FROM EMPLOYEE ORDER BY 5;
В качестве примера использования функции DECODE приведем запрос, вычисляющий список служащих с указанием их руководителя. Если руководитель неизвестен, то выводится по умолчанию "не имеет".
SELECT ENAME, DECODE(DEPNO, 10, 'Дрягин', 20,'Жиляева', 30,' Коротков', 'не имеет') FROM EMPLOYEE ORDER BY ENAME;
Предположим, что руководитель организации имеет неопределенное значение колонки DEPNO и, следовательно, для него будет работать умолчание, предусмотренное в DECODE.
SQL и его история
Единственным средством общения и администраторов баз данных, и проектировщиков, и разработчиков, и пользователей с реляционной базой данных является структурированный язык запрос SQL (Structured Query Language). SQL есть полнофункциональный язык манипулирования данными в реляционных базах данных. В настоящее время он является общепризнанным, стандартным интерфейсом для реляционных баз данных, таких как Oracle, Informix, Sybase, DB/2, MS SQL Server и ряда других (стандарты ANSI и ISO). SQL - непроцедурный язык, который предназначен для обработки множеств, состоящих из строк и колонок таблиц реляционной базы данных. Хотя существуют его расширения, допускающие процедурную обработку. Проектировщики баз данных используют SQL для создания всех физических объектов реляционной базы данных.Теоретические основы SQL были заложены в известной статье [Кодд], положившей начало развитию теории реляционных БД. Первая практическая реализации была выполнена в исследовательских лабораториях фирмы IBM Chamberlin D.D. и Royce R.F. Промышленное применение SQL было впервые реализовано в СУБД Ingres. Одной из первых промышленных реляционных СУБД является Oracle. По сути дела, реляционная СУБД - это программное обеспечение, которое управляет работой реляционной базы данных.
Первый международный стандарт языка SQL был принят в 1989 г. (SQL-89). В конце 1992 г. был принят новый международный стандарт SQL-92. В настоящее время большинство производителей реляционных СУБД используют его в качестве базового. Однако работы по стандартизации языка SQL далеки от завершения и уже разработан проект стандарта SQL-99, который вводит в обиход языка понятие объекта и разрешает на него ссылаться в операторах SQL. В исходном варианте SQL не было команд управления потоком данных, они появились в недавно принятом стандарте ISO/IEC 9075-5: 1996 дополнительной части SQL.
Каждой конкретной СУБД соответствует своя собственная реализация SQL, в целом поддерживающая определенный стандарт, но имеющая свои особенности. Эти реализации называются диалектами. Так, стандарт ISO/IEC 9075-5 предусматривает объекты, называемые постоянно хранимыми модулями или PSM-модулями (Persistent Stored Modules). В СУБД Oracle расширение PL/SQL является аналогом указанного выше расширения стандарта 1.
Основы проектирования реляционных баз данных
Циклы зависимых таблиц
Использование ограничений ссылочной целостности может порождать так называемые ссылочные циклы. Для пояснения этого понятия обратимся к учебной базе данных. Таблица EMPLOYEE содержит колонку DEPNO (внешний ключ, содержащий ссылку на таблицу DEPARTAMENT). Если добавить в таблицу EMPLOYEE колонку MNGR, которая определяет руководителя каждого служащего, а в таблицу DEPARTAMENT - колонку с номером руководителя MRGNO, то мы получим пример ссылочного цикла (при определении ссылочной целостности по этим атрибутам).Такой вид циклической связи порождает проблемы для операций манипулирования данными. Допустим, что на работу принят служащий, который должен руководить вновь созданным отделом 100. Последовательное выполнение операторов INSERT будет неуспешным (строка в дочерней таблице EMPLOYEE ссылается на отдел, которого еще нет, и такого менеджера еще не существует).
INSERT INTO EMPLOYEE (EMPNO,ENAME,LNAME,DEPNO, JOB,AGE,HIREDATE,SAL,COMM,FINE,MNGR) VALUES(4000,"Анисимов","Виктор",100,"Менеджер",,2500000,,,NULL);
INSERT INTO DEPARTAMENT (DEPNO, DNAME, LOC, MANAGER, MRGNO,PHONE) VALUES (100,'Маркетинг','Москва', 'Анисимов', 4000,1352519);
Операция добавления в базу данных записей, связанных с организацией нового отдела и прихода его руководителя, при поддержке ссылочной целостности в случае ссылочного цикла будет следующей:
INSERT INTO EMPLOYEE (EMPNO,ENAME,LNAME,DEPNO, JOB,AGE,HIREDATE,SAL,COMM,FINE,MNGR) VALUES(4000, "Анисимов","Виктор",NULL, "Менеджер",,2500000,,,NULL);
INSERT INTO DEPARTAMENT (DEPNO, DNAME, LOC, MANAGER, MRGNO,PHONE) VALUES (100,'Маркетинг','Москва', 'Анисимов', 4000,1352519);
UPDATE EMPLOYEE SET DEPNO=100 WHERE EMPNO=4000;
Аналогичным образом могут, при наличии ссылочных циклов, возникать проблемы с операцией удаления кортежей в родительской и дочерних таблицах. Следует избегать наличия ссылочных циклов в таблицах. Так, для учебной базы данных добавление новых полей и установка для них ограничений ссылочной целостности совсем не обязательна.
Более подробное описание работы с ограничениями ссылочной целостности приводятся в соответствующих руководствах фирм - изготовителей СУБД.
В этом разделе мы изучили ограничения, которые поддерживаются в реляционной базе данных средствами СУБД. Такие ограничения представляют встроенные в СУБД механизмы обеспечения целостности данных и поддержку ссылочной целостности. Исходными данными для наложения ограничений являются бизнес-правила предметной области базы данных. Решение о том, как будут использоваться эти бизнес-правила при проектировании физической модели базы данных в рамках предоставляемых СУБД механизмов добавления ограничений, находится полностью в компетенции проектировщиков баз данных. Проектировщик базы данных может принять решение о том, что ссылочная целостность будет контролироваться через триггеры, а целостность данных будет отдана на откуп разработчикам программ или опять же будут использованы триггеры. Или для выполнения такого контроля будет предусмотрено специальное приложение базы данных, или такой контроль будут осуществлять организационными мероприятиями.
Ниже приведен типичный синтаксис команды ALTER TABLE.
Типичный синтаксис команды ALTER TABLE (без учета ссылочной целостности):
ALTER TABLE имя_таблицы DROP [имя_колонки [,имя_колонки ѕ]] ADD имя_колонки тип_данных [(размер)] [NOT NULL | NOT NULL WITH DEFAULT] RENAME имя_колонки новое_имя | TABLE новое_имя MODIFY имя_колонки тип_данных [(размер)] [NULL | NOT NULL | NOT NULL WITH DEFAULT]
Добавление CHECK-ограничения в спецификацию колонки
Ограничение CHECK позволяет выполнять проверку содержимого колонки относительно некоторых условий и списка значений. Она налагается с помощью предложения CHECK. Для добавления этого ограничения нужно после объявления столбца в спецификации колонки определить синтаксическую конструкцию CHECK (предикат). Согласно требованиям стандарта с помощью ключевого слова VALUE в предикате вы ссылаетесь на значение колонки. Но практически во всех диалектах для этой цели используется имя колонки.Пример. В учебной базе данных в таблице EMPLOYEE для сотрудников может указываться признак пола: 0 - мужской, 1 - женский. Бизнес-правило предметной области для значений этого поля может быть сформулировано так:
Лицо, принимаемое на работу, может иметь один из двух допустимых признаков пола.
Тогда спецификация колонки может выглядеть так:
SEX int NOT NULL CHECK (SEX=0 OR SEX=1),
Добавление колонок в таблицы
Следующим шагом проектировщика базы данных является определение колонок для базовых таблиц. Колонки таблицы должны представлять атрибуты отношений логической модели реляционной базы данных. Эти атрибуты необходимо преобразовать в спецификации колонок в команде CREATE TABLE. Спецификация колонки таблицы имеет следующий синтаксис: имя колонки, тип данных для значений, сохраняемых в колонке, список ограничений.Сначала рассмотрим задачу добавления колонок. Колонка должна иметь имя. Имена атрибутов соответствующих отношений логической модели преобразуются в имена колонок в соответствии с правилами именования объектов, принятых в конкретной СУБД. Обычно, как указывалось выше, это ограничение на длину имени и использование в имени специальных символов. Например, в некоторых СУБД допускается использовать знак доллара в имени, однако этот знак обычно не распознается в командах выборки данных - SELECT.
Имеется еще одна проблема в именовании колонок: имена колонок должны интерпретироваться пользователем однозначно. Например, если проектировщик базы данных назначит для фамилии сотрудника короткое имя LN, то, наверное, потребуется комментарий, в котором необходимо указать, что это фамилия, а не линия (например, линия производства). Если невозможно по каким-то причинам применять длинные имена полей, то следует использовать словарь данных для интерпретации введенных аббревиатур.
При назначении имен колонок проектировщик базы данных продолжает формировать стандартный список имен колонок и их сокращений в словаре данных. Он также должен выполнить проверку списка имен в словаре данных, чтобы избежать конфликтов имен в базе данных в целом.
Пример. Продолжим работу с учебным примером. После именования колонок получим следующее:
CREATE TABLE DEPARTAMENT ( DEPNO, имя колонки DNAME, LOC, MANAGER, PHONE, );
CREATE TABLE EMPLOYEE ( EMPNO, ENAME, LNAME, DEPNO, SSECNO, PROJNO, JOB, AGE, HIREDATE, SAL, COMM, FINE, ); CREATE TABLE PROJECT ( PROJNO, PNAME, BUDGET, );
Добавление ограничения первичного ключа и внешнего ключа
Мы уже рассматривали вопрос о задании ограничений первичного ключа в предыдущем разделе. Там же был показан пример задания ограничений внешнего ключа при разрешении связей "многие-ко-многим". Более детально мы разберем работу с ограничением внешнего ключа при обсуждении поддержки ссылочной целостности ниже.Добавление ограничения UNIQUE в спецификацию колонки
Ограничение UNIQUE гарантирует уникальность значения данных в колонке. Оно используется, если нужно следить за тем, чтобы значения колонки, не являющейся первичным ключом, были уникальны в таблице. При этом проверяется уникальность всех значений, отличных от NULL.Пример. В учебной базе данных в таблице EMPLOYEE используется номер социальной страховки SSECNO, для которого бизнес-правило состоит в том, что для каждой персоны, если она имеет такой номер, он должен быть уникальным. Установить уникальность этих номеров можно следующей спецификацией колонки:
SSECNO char(10) UNIQUE,
Ограничение UNIQUE можно определить также в конце команды CREATE TABLE в следующей синтаксической форме: UNIQUE (SSECNO).
Добавление, удаление и блокирование ограничений
Ограничения задаются в спецификациях колонки или спецификациях ключей при создании таблицы в командах SQL CREATE TABLE или налагаются после создания таблицы в командах SQL ALTER TABLE. Как добавить ограничения в таблицу с помощью команды CREATE TABLE, мы уже знаем. Чтобы добавить ограничения с помощью команды ALTER TABLE, можно поступать следующим образом.Пример. Для нашей учебной базы данных мы могли бы не определять первичный ключ в таблице EMPLOYEE в команде CREATE TABLE и после нее выполнить команду
ALTER TABLE EMPLOYEE PRIMARY KEY (EMPNO);
Аналогично, мы могли бы установить ограничение внешнего ключа в таблице EMP_PRJ следующим образом:
CREATE TABLE EMP_PRJ ( EMPNO integer NOT NULL, PROJNO char(8) NOT NULL, WORKS number, PRIMARY KEY (EMPNO, PROJNO), ); ALTER TABLE EMP_PRJ FOREING KEY (EMPNO) REFERENCES EMPLOYEE ON DELETE RESTRICT, FOREING KEY (PROJNO) REFERENCES PROJECT ON DELETE RESTRICT;
Чтобы удалять ограничения первичного и внешнего ключей, можно использовать команду ALTER TABLE в синтаксической форме
ALTER TABLE EMPLOYEE DROP PRIMARY KEY (EMPNO);
В СУБД Oracle 9i для создания ограничений на уровне таблицы используется следующий синтаксис команды ALTER TABLE:
ALTER TABLE имя_таблицы ADD CONSTRAINTS ограничение TYPE(колонка);
а для удаления
ALTER TABLE имя_таблицы DROP CONSTRAINTS ограничение.
Кроме этого, в СУБД Oracle 8i можно блокировать и деблокировать действие ограничений с помощью опций DISABLE и ENABLE команды ALTER TABLE, как показано в примере ниже:
ALTER TABLE EMPLOYEE DISABLE PRIMARY KEY; ALTER TABLE EMPLOYEE ENABLE PRIMARY KEY;
После использования опции DISABLE ограничение становится неактивным, но его определение остается в словаре базы данных. Вы можете вернуть активность ограничению с помощью опции ENABLE. Использование опции DROP полностью удаляет ограничение из базы данных (и словаря базы данных также).
Использование опции DEFAULT
Опция DEFAULT заставляет СУБД размещать значение по умолчанию в колонке, когда кортеж вставляется в таблицу и никакого значения колонки не представлено. Чтобы указать значение по умолчанию, нужно в спецификацию колонки добавить ключевое слово "DEFAULT" и после него указать любое значение, являющееся достоверным экземпляром типа данных колонки.Пример. Для нашей учебной базы данных мы могли бы определить значение по умолчанию для числовых колонок в таблице EMPLOYEE:
SAL dec(9,2) DEFAULT(0), COMM dec(9,2) DEFAULT(0), FINE dec(9,2) DEFAULT(0),
Назначение первичных ключей таблицам
После определения всех колонок и их типов следует перейти к идентификации первичных ключей таблицы. Согласно требованиям реляционной теории каждая строка таблицы (кортеж) должна иметь уникальный первичный ключ. Обычно хорошим кандидатом на первичный ключ таблицы является первичный ключ отношения логической модели. Поскольку предполагается, что в отношении логической модели задан первичный ключ, обладающий свойством минимальности, то его просто нужно определить в команде CREATE TABLE. Такое определение первичного ключа таблицы для многих таблиц не является окончательным. Переопределение первичного ключа может происходить на следующих этапах физического проектирования базы данных.Задание колонки как первичного ключа в контексте многих СУБД, в том числе и Oracle, считается ограничением на значение колонки (см. следующий подраздел).
Стандартом SQL-92 предусмотрено специальное предложение PRIMARY KEY команды CREATE TABLE для спецификации первичного ключа таблицы. Атрибуты первичного ключа перечисляются через запятую и заключаются в круглые скобки. Если спецификация PRIMARY KEY не определяется, то считается, что таблица не имеет первичного ключа. При этом допускается дублирование строк в таблице.
Пример. Для нашего примера колонками первичного ключа могут быть назначены: колонка DEPNO в отношении DEPARTAMENT, колонка EMPNO в отношении EMPLOYEE, колонка PROJNO в отношении PROJECT.
CREATE TABLE DEPARTAMENT ( DEPNO integer, DNAME char(20), LOC char(20), MANAGER char(20), PHONE char(15), PRIMARY KEY (DEPNO) определение первичного ключа );
CREATE TABLE EMPLOYEE ( EMPNO integer, ENAME char(25), LNAME char(10), DEPNO int, SSECNO char(10), PROJNO char(8), J OB char(25), AGE date, HIREDATE date, SAL dec(9,2), COMM dec(9,2), FINE dec(9,2), PRIMARY KEY (EMPNO) );
CREATE TABLE PROJECT ( PROJNO char(8), PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) );
В СУБД Oracle можно задавать ограничение первичного ключа, т.е. определять колонку как первичный ключ, как часть спецификации колонки, а не как часть спецификации таблицы (см.
пример выше). При использовании такой техники команда CREATE TABLE будет выглядеть так, как показано ниже для таблицы DEPARTAMENT:
CREATE TABLE DEPARTAMENT ( DEPNO integer primary key, определение первичного ключа DNAME char(20), LOC char(20), MANAGER char(20), PHONE char(15), );
Когда вы определяете PRIMARY KEY при создании таблицы, многие реляционные СУБД требуют обязательного создания уникального индекса первичного ключа. Индексы, так же как и таблицы, являются объектами реляционной базы данных (но не реляционной модели). Логически индексы представляют собой таблицу, в которой каждому значению индексируемой колонки ставится в соответствие некоторая информация, связанная с ее месторасположением на физическом носителе. Индексы предназначены для организации быстрого доступа к строкам таблицы и обеспечения контроля целостности данных (механизм индексов будет блокировать вашу базу данных от повторного ввода строк в таблицу с одинаковыми значениями индексируемых атрибутов). Индекс создается с помощью команды
CREATE UNIQUE INDEX NDXDEPT ON DEPARTAMENT (DEPNO);
Предложение CREATE INDEX определяет имя индекса, предложение ON определяет имя таблицы и колонок, для которой и по которым строится индекс, ключевое слово UNIQUE указывает, что индексируемые значения колонок должны быть уникальными для таблицы, т.е. исключается дублирование значений в индексируемой колонке. Таблица должна быть уже создана, и должна содержать определения индексируемых столбцов. Спецификация UNIQUE опциональна, и вы можете также создавать и неуникальные индексы.
Следует помнить, что для многих СУБД целостность первичного ключа поддерживается заданием уникального индекса на колонку ключа, иначе создание таблицы считается незавершенным.
Поэтому для завершения процедуры определения первичных ключей базовых таблиц проектировщик базы данных должен будет добавить в скрипт три команды CREATE UNIQUE INDEX, как показано ниже:
CREATE UNIQUE INDEX NDXDEPT ON DEPARTAMENT (DEPNO); CREATE UNIQUE INDEX NDXEMPLOYEE ON EMPLOYEE(EMPNO); CREATE UNIQUE INDEX NDXPROJECT ON PROJECT(PROJNO);
Для диалекта SQL СУБД Oracle этого делать не нужно, т.к. она автоматически поддерживает целостность первичного ключа.
После выполнения вышеперечисленных действий задачу определения первичных ключей базовых таблиц в первом приближении можно считать законченной и перейти к решению следующей очень важной задачи определения таблиц - определению ограничений на значения колонок.
Обавление NOT NULL ограничения в спецификацию колонки
NOT NULL ограничение гарантирует, что колонка всегда содержит значения. СУБД не будет разрешать вставлять или обновлять строку таблицы, если в ней существует колонка с ограничением NOT NULL, а данных для этой колонки в добавляемой строке не представлено. Как мы уже видели выше, для колонок первичного ключа это ограничение нужно устанавливать всегда.Пример. Для нашей учебной базы данных действует правило, что сотрудник всегда должен иметь имя и фамилию. Чтобы удовлетворить этому правилу, нужно определить следующую спецификацию колонок ENAME и LNAME в таблице EMPLOYEE:
ENAME char(25) NOT NULL, LNAME char(10) NOT NULL,
Иногда ограничение NOT NULL используется вместе с опцией DEFAULT, как это было определено в спецификации колонки HIREDATE (дата приема на работу) в таблице EMPLOYEE:
HIREDATE date NOT NULL WITH DEFAULT,
Ограничения и их использование в реляционной базе данных
В предыдущих разделах мы уже сталкивались с несколькими типами ограничений в спецификациях колонок - NOT NULL, и ограничениях в таблицах - PRIMARY KEY, FOREING KEY. В данном разделе мы изучим практически все виды ограничений, которые поддерживаются в реляционных базах данных. Ограничения являются важным инструментом проектировщика базы данных, с помощью которого он поддерживает целостность (strong) базы данных. Их можно использовать для того, чтобы быть уверенным в том, что колонка первичного ключа таблицы является уникальной и всегда содержит значения. Ограничения используются также для поддержки ссылочной целостности. Последнее означает, что значения в колонке внешнего ключа должны существовать как некоторое значение в колонке первичного ключа другой таблицы.Замечание. Одна из главных концепций реляционной базы данных состоит в том, что всегда целесообразнее заставлять саму базу данных поддерживать свою непротиворечивость, чем заставлять решать эту задачу приложение базы данных. Вопрос о том, что лучше: передавать поддержку ограничений приложениям базы данных или оставлять самой базе данных, - остается все еще открытым.
Ограничения представляют собой способ применения бизнес-правил предметной области на уровне базы данных и гарантируют совместимость вводимых данных с теми, которые уже находятся в таблицах. В реляционной базе данных под ограничением понимается правило (условие), которому должен удовлетворять некоторый элемент в базе данных. Например, условия, которым должны дополнительно удовлетворять значения колонки таблицы в рамках определенного для нее типа данных (т.е. тип данных плюс правило), полностью воплощают концепцию домена в физической модели реляционной базы данных.
Как мы видели выше, ограничения могут применяться на уровне колонки (ограничения колонки) или на уровне таблицы (ограничения таблицы). Ограничения первичного ключа - это ограничения, действующие на уровне таблицы, а NOT NULL ограничения - это ограничения на уровне колонки. Существуют три основных типа ограничений, используемых в реляционной базе данных, - ограничения целостности данных, ограничения целостности ссылок и ограничения первичного ключа.
Ограничения целостности данных (data integrity constraints) относятся к значениям данных в некоторых колонках и определяются в спецификации колонки с помощью элементов SQL NOT NULL, UNIQUE, CHECK. Ограничения целостности ссылок (referential constraints) относятся к связям между таблицами на основе связи первичного и внешнего ключей. Ограничения первичного ключа относятся к значениям данных в колонках первичного ключа таблицы и должно налагаться на каждую базовую таблицу реляционной базы данных. В таблице ниже приведен список ограничений, применяемых в реляционных базах данных.
| Ограничение | Описание | |
Определение базовых таблиц
Как указывалось выше, первый шаг в построении внутренней схемы есть идентификация реляционной таблицы, которая будет сохраняться в базе данных. При решении этой задачи проектировщик базы данных имеет на входе отношения логической модели реляционной базы данных, представляющие сущности предметной области, а на выходе должен создать набор макетных команд CREATE TABLE, которые будут использоваться далее для добавления колонок и других деталей.Базовые таблицы создаются для каждого отношения логической модели и являются главными объектами хранения данных в базе данных. Для каждой базовой таблицы определяется длинный идентификатор, который уникально идентифицирует таблицу в базе данных. Это имя должно соответствовать стандартам наименований сущностей предметной области базы данных, если такие стандарты были разработаны администратором данных на стадии анализа предметной области базы данных. Имена таблиц должны быть занесены проектировщиком базы данных в словарь данных базы данных.
Далее проектировщик базы данных формирует список всех пользователей каждой таблицы. При этом выделяются так называемые владельцы таблицы, т.е. пользователи, которые имеют все права доступа к таблице. Этот список используется на завершающем этапе проектирования физической структуры базы данных при авторизации пользователей и разграничении полномочий доступа.
Когда проектировщик заканчивает обработку всех отношений логической модели данных, он должен еще раз проверить, чтобы число базовых таблиц соответствовало числу отношений логической модели реляционной базы данных (т.е. было не меньше, чем число сущностей предметной области базы данных). Таким образом, при создании базовых таблиц проектировщик базы данных придерживается принципа "каждому отношению логической модели базы данных по базовой таблице".
Пример. Для нашего учебного примера результат решения задачи настоящего пункта может иметь следующий вид:
CREATE TABLE DEPARTAMENT имя таблицы ( ); CREATE TABLE EMPLOYEE имя таблицы ( ); CREATE TABLE PROJECT имя таблицы ( );
Определение типов данных для колонок
После идентификации колонок необходимо задать их тип в соответствии с допустимыми для данной СУБД типами данных. Эта задача упрощается, если в отношениях логической модели определены домены атрибутов. Некоторые из доменов могут быть определены уже в терминах СУБД. Для таких атрибутов практически ничего делать не нужно. Определение домена в терминах типа данных СУБД нужно просто перенести в спецификацию колонки. Возможно, проектировщику будет нужно уточнить второстепенные параметры типа. Например, если задан домен как DEC (9,2), а из контекста предметной области следует, что в этой колонке будет накапливаться итоговая сумма расходов за год, то может быть целесообразным определить тип как DEC (15,2), чтобы избежать возможного переполнения при работе приложений базы данных.Если домен определен не в терминах СУБД, проектировщик базы данных должен преобразовать его в подходящий тип данных. При выполнении таких преобразования следует учитывать ряд факторов.
Во-первых, может потребоваться дополнительная проверка, а во-вторых, могут возникнуть проблемы при сортировке таких колонок, поскольку число, заданное строкой '11', будет находиться выше, чем число, заданное строкой '9', при упорядочивании по возрастанию.
Пример. Продолжим изучение нашего примера. После определения типов колонок наши команды для создания таблиц будут выглядеть следующим образом:
CREATE TABLE DEPARTAMENT ( DEPNO integer, имя колонки, тип, длина DNAME char(20), LOC char(20), MANAGER char(20), PHONE char(15), );
CREATE TABLE EMPLOYEE ( EMPNO integer, ENAME char(25), LNAME char(10), DEPNO int, SSECNO char(10), PROJNO char(8), JOB char(25), AGE date, HIREDATE date, SAL dec(9,2), COMM dec(9,2), FINE dec(9,2), );
CREATE TABLE PROJECT ( PROJNO char(8), PNAME char(25), BUDGET dec(9,2), );
Особенности манипулирования данными при ограничениях ссылочной целостности
Естественно, что ограничения ссылочной целостности (фиксируя в базе данных связи между таблицами и отслеживая их) оказывают действие на команды манипулирования данными. Такие действия регламентируют правила использования данных команд, в случае, когда таблица имеет внешний ключ.Для команды INSERT предусмотрены следующие правила:
Для команды UPDATE предусмотрены следующие правила:
Попытка обновить первичный ключ родительской таблицы возможна лишь тогда, когда ему не соответствует ни одного значения внешнего ключа в таблицах-потомках, причем сделать это можно только для одной строки таблицы в команде UPDATE.
Правила для команды DELETE сообщают СУБД, что ей делать, когда пользователь пытается удалить строку в таблице-родителе. Отметим также, что в командах удаления нельзя использовать подзапрос, ссылающийся на заданную в команде таблицу.
Применение команды DROP в условиях ограничений ссылочной целостности также имеет свои особенности. Так, когда вы удаляете таблицу-родитель или первичный ключ, ограничения ссылочной целостности разрушаются. Если вы удаляете первичный индекс, то вы не разрушаете ограничений ссылочной целостности, но таблица становится незавершенной. Удаление первичного или внешнего ключа физически не удаляет соответствующие колонки.
Отношение "родитель-потомок" между таблицами
Первичный и соответствующий ему внешний ключ позволяют реализовать отношение "родитель-потомок" (parent/child relationship) между таблицами. Они отражают взаимосвязь между объектами предметной области (представленными кортежами таблиц) через значения некоторых их атрибутов по принципу иерархического подчинения, когда объект-родитель определяет существование объектов-потомков. Сами объекты-потомки могут также выступать в качестве родителей для других объектов (descendents).Таблица реляционной базы данных, содержащая первичный ключ, называется таблицей-родителем (parent table) или родительской таблицей, а таблица, содержащая соответствующий первичному ключу внешний ключ, - таблицей-потомком (child table) или дочерней таблицей. Таблица DEPARTAMENT учебной базы данных является таблицей-родителем для таблицы EMPLOYEE.
Таблица базы данных может не иметь ни родителей, ни потомков. Такие таблицы называются независимыми таблицами (independent tables). Они не удовлетворяют никаким ограничениям ссылочной целостности и СУБД не контролирует и не проверяет правильность ссылок к таким таблицам.
Отношение "родитель-потомок" между таблицами реализуется через атрибуты-ключи соответствующих строк. Строка, принадлежащая таблице-родителю, называется родительской строкой, а строка в таблице-потомке, на которую ссылается родительская строка, называется строкой-потомком или дочерней строкой. Строка-потомок должна иметь по крайней мере один ненулевой атрибут внешнего ключа.
Совсем необязательно, чтобы каждая строка таблицы-родителя была родительской строкой. Аналогично, если строка в таблице-потомке имеет нуль-значение внешнего ключа, то она не будет строкой-потомком.
Отношение "родитель-потомок" между двумя таблицами отражает взаимосвязь по включению на доменах соответствующих атрибутов. Однако, таблица может реализовать отношение иерархического подчинения в самой себе. Примером такой таблицы может стать виртуальная таблица из этой лекции, реализующая отношение Руководитель-подчиненный, если ее сделать таблицей базы данных.
Первичные и внешние ключи
Понятие первичного ключа как уникального идентификатора кортежа отношения уже обсуждалось выше. Здесь нас интересует другой аспект данного понятия. А именно - то, что первичный ключ может гарантировать целостность данных. Если первичный ключ корректно используется, все кортежи отношения остаются различными и отсутствуют кортежи, у которых все атрибуты имеют нуль-значения. Напомним основные свойства первичного ключа:Поддержка ссылочной целостности посредством первичного ключа осуществляется через его индекс. Уникальный индекс для первичного ключа отношения называется первичным индексом. Как правило, первичный индекс должен быть единственным для отношения. Если первичный индекс не создан, таблица реляционной базы данных находится в незавершенном состоянии. В такой таблице вы не можете искать, вставлять, удалять или модифицировать строки. Также невозможно создать внешний ключ для ссылки на первичный ключ таблицы.
Замечание. В СУБД Oracle 9i первичный индекс создается автоматически.
В конкретных реализациях СУБД существуют дополнительные ограничения на определение первичного ключа. Так, в SQLBase первичный ключ не может включать более 16 колонок, общая длина первичного ключа не может превышать 255 байт, нельзя использовать колонки типа LONG/LONG VARCHAR, в самоссылающихся строках значение первичного ключа невозможно модифицировать.
Внешний ключ представляет собой ссылку на первичный ключ в данной или другой таблице, т.е. один или несколько атрибутов отношения, которые содержат первичный ключ другого отношения. Примером внешнего ключа является номер отдела DEPNO в таблице EMPLOYEE нашей учебной базы данных.
Из определения следует, что внешний ключ может быть создан только после создания соответствующего первичного ключа (и первичного индекса).
Внешнему ключу обычно назначается специальное имя. Внешние ключи имеют следующие свойства:
Поддержка ссылочной целостности посредством внешних ключей не требует соответствующего индекса для внешнего ключа. Однако наличие такого индекса иногда может улучшить производительность базы данных.
В SQLBase существуют ограничения на определение внешнего ключа:
В других СУБД ограничения на определение внешнего ключа носят аналогичный характер.
Понятие внешней схемы
При обсуждении представлений мы уже касались понятия внешней схемы. В этом подразделе мы остановимся на этом понятии более подробно. Создание внешней схемы является желательным, но совсем не обязательным действием проектировщика данных.В архитектуре трех схем ANSI/SPARC внешняя схема используется для изоляции требований к данным пользователей и приложений от физического размещения данных. Такая изоляция по определению делает пользователей независимыми от аспектов физической модели реляционной базы данных, включающих возможности СУБД и программно-аппаратной платформы. Эта изоляция делает пользователей также независимыми и от информационной модели предметной области, и от логической структуры базы данных или от стратегической политики обработки данных в масштабе организации, которая может быть неестественной для представления данных конкретного пользователя. Таким образом, под внешней схемой принято понимать такую организацию представления данных в базе данных, которое наиболее естественным и простым способом отражало бы взгляд пользователей на эти данные, когда они их обрабатывают. Цель разработки внешней схемы состоит в том, чтобы скрыть от пользователя особенности реализации физической модели базы данных.
В настоящее время стандарт SQL, так же как и большинство промышленных СУБД, не говоря уже об экспериментальных СУБД, обеспечивают поддержку внешней схемы ограниченно. Основным способом изоляции требований пользователей к данным от особенностей их физического хранения является механизм реляционных представлений, который мы обсуждали выше.
Приведем примеры, когда изменения на уровне физической организации базы данных могут быть скрыты от пользователей с помощью представлений.
Создание внешней схемы является в большей степени задачей администратора базы данных, чем задачей проектировщика. Более того, стоимость сопровождения представлений внешней схемы будет определяться стоимостью работ администратора базы данных по созданию и сопровождению представлений, а также по обеспечению безопасности, так как потребуется дополнительная авторизация доступа к представлениям.
Представления и множества
Представления (виртуальные таблицы) позволяют вам явным образом именовать результирующие отношения, получающиеся в промежуточных реляционных операциях, и использовать их как самостоятельные отношения. Так вы можете результату вложенного подзапроса (непоименованное отношение) присвоить имя и применять это отношение вместо вложенного подзапроса как самостоятельное.Концепция представления особенно важна, когда требуется извлекать информацию из нескольких отношений. Во-первых, она является средством формирования пользователем своей виртуальной (внешней) схемы базы данных. Во-вторых, это средство формирования производных или выводимых атрибутов отношений базы данных, то есть таких атрибутов, которые непосредственно не хранятся в базе данных. Представление можно трактовать как макроопределение: любой запрос по отношению к нему подвергается макрорасширению и преобразуется SQL для ссылки на исходные базовые отношения. Чтобы представление (как производное отношение) стало доступно, вам необходимо дать ему уникальное имя и определить атрибуты.
Обратимся к примеру с футболом. Пусть имеется некоторая база данных, которая содержит всю информацию о чемпионате мира по футболу. Допустим, что вас интересует информация о стадионах и об играх, закончившихся с определенной разностью забитых и пропущенных мячей. Тогда вы можете первоначально определить представление как
CREATE VIEW СТАДРАЗН (стад, разн_мячей ) AS SELECT стадион, голыА - голыВ FROM ИГРЫ, РАЗМ_СТАДИОНОВ WHERE ИГРЫ.год = РАЗМ_СТАДИОНОВ.год AND ИГРЫ.группа = 2 АND РАЗМ_СТАДИОНОВ.группа=2 АND ИГРЫ.игра=РАЗМ_СТАДИОНОВ.игра
В этом примере также демонстрируется, как определять производные колонки в представлении.
Теперь вы можете выполнить запрос к виртуальной таблице, такой, чтобы получить ответ на вопрос: выдать все стадионы, на которых игры закончились с разностью мячей больше 4. Команда языка SQL в этом случае тривиальна:
SELECT стад FROM СТАДРАЗН WHERE разн_мячей > 4;
Таким образом, представление в алгебре отношений является операцией наименования промежуточных результатов.
Представления и независимость данных
Как вы могли видеть, виртуальные таблицы освобождают пользователя от необходимости знать, как хранятся данные. Пользователь имеет внешнюю схему (виртуальные таблицы), база данных определяется внутренней схемой (таблицы данных). Независимость данных определяется наличием двух уровней абстракции в представлении данных. Поддержка независимости данных для пользователя во многом упрощает работу с данными.Рассмотрим пример из предыдущего раздела. Примененная схема базы данных учебного примера не позволяет использовать одного служащего в нескольких проектах (реализовано отношение "много (служащих) к одному (проекту)"). На практике обычно каждый служащий работает над несколькими проектами (отношение "многие-ко-многим"). Чтобы реализовать такое отношение, необходимо модернизировать структуру базы данных. При этом все ранее разработанные приложения и виртуальные таблицы должны работать соответствующим образом. Также следует использовать новые возможности. Определим отношение "многие-ко-многим" через создание новой таблицы PREM:
CREATE TABLE PREM ( EMPNO integer, PROJNO char(8), WORKS number);
которая будет служить для распределения служащих по проектам. В этой таблице каждому служащему отвечает столько строк, сколько проектов он выполняет. Колонка PROJNO таблицы EMPLOYEE при этом потеряла свой семантический смысл. Удалим эти данные:
UPDATE EMPLOYEE SET PROJNO=NULL;
При этом мы уже не можем пользоваться виртуальной таблицей PERSPROJ, которая использует эту колонку для соединения таблиц EMPLOYEE и PROJECT. Чтобы для пользователя ничего не изменилось, следует переопределить виртуальную таблицу PERSPROJ. Для этого удалим ее с помощью команды SQL DROP. Команда DROP является в SQL универсальной командой для удаления объектов реляционной базы данных: вы только должны определить, что вы хотите удалить: TABLE, VIEW или иной объект.
Удалим определение неподходящей виртуальной таблицы:
DROP VIEW PERSPROJ;
Создадим новую виртуальную таблицу с тем же именем, но учитывающую изменения в схеме базы данных:
CREATE VIEW PERSPROJ AS SELECT ENAME, JOB, PNAME FROM EMPLOYEE, PROJECT, PREM WHERE EMPLOYEE.EMPNO=PREM.EMPNO AND PREM.PROJNO=PROJECT.PROJNO;
Колонку PROJNO в таблице EMPLOYEE следует удалить за ненадобностью:
ALTER TABLE EMPLOYEE DROP PROJNO;
Вы видите, как легко изменить структуру базы данных, не внося слишком больших изменений в ваши приложения и используемые запросы (на виртуальных таблицах). Это объясняется тем, что SQL является непроцедурным языком, т.е. ваши программы и запросы не привязываются к структуре базы данных. За счет модификации виртуальных таблиц вы можете скрыть фактические изменения структуры базы данных от пользователя. Рассмотренный выше пример иллюстрирует основные моменты реализации концепции независимости данных в реляционных базах данных.
Синонимы
Синоним есть другое имя для таблицы или представления. Синонимы используются для того, чтобы сделать базу данных более дружественной для пользователя. Это означает, что объектам базы данных, которые попадают в сферу внимания пользователей, назначаются альтернативные, длинные имена в терминах предметной области базы данных. Такие имена более понятны неподготовленным пользователям базы данных и не будут создавать дополнительных психологических препятствий в работе с базой данных. С другой стороны, если объекты базы данных носят длинные имена, то их неудобно использовать в часто выполняемых запросах, т.к. каждый раз приходится набирать длинную последовательность символов. Синоним позволяет ввести сокращенное имя.Задача назначения синонимов объектам базы данных является задачей администратора данных организации или администратора базы данных. Проектировщик может определить синонимы объектам базы данных, но он должен согласовать свои действия с администратором данных. Если синонимы определяются проектировщиком, то должен быть составлен список синонимов для передачи его администратору данных. Синонимы хранятся в словаре базы данных.
Синоним по определению может быть общим для всех пользователей базы данных (PUBLIC) или принадлежать пользователю (USER), который его создал. Опция PUBLIC позволяет обращаться к таблице с помощью синонима без уточнения имени таблицы именем владельца. Чтобы создать или удалить синоним PUBLIC, необходимо либо быть владельцем таблицы, либо иметь привилегии пользователей SYS или SYSTEM (Oracle). (Для СУБД SQLBase DBA или SYSADM соответственно.)
Пример. Для нашей учебной базы данных вы можете создать синоним EMP для таблицы EPMPLOYEE с помощью следующей команды:
CREATE PUBLIC SYNONYN EMP FOR EPMPLOYEE;
Или для пользователя SYS:
CREATE SYNONYN SYS.EMPL FOR EPMPLOYEE;
Чтобы удалить синоним EMP таблицы EPMPLOYEE, необходимо использовать команду
DROP PUBLIC SYNONYN EMP;
Создание начальной внутренней схемы реляционной базы данных
В настоящем разделе будет рассмотрена первая профессиональная задача проектировщика базы данных по созданию физической модели реляционной базы данных - создание объектов для хранения данных. Эта задача сводится к созданию таблиц и объектов в базе данных, в которых будет храниться информация о сущностях предметной области. Решая эту задачу, проектировщик базы данных отображает отношения логической модели реляционной базы данных (сущности предметной области, представленные в нормализованной форме на ER-диаграммах) в таблицы и индексы реляционной базы данных. Для выполнения этой задачи используется подмножество команд SQL - язык определения данных DDL (Data Definition Language) (например, для СУБД Oracle эти действия могут быть выполнены в программе SQL*PLUS).В рамках концепции трехуровневой архитектуры баз данных ANSI/SPARC эту задачу проектировщика базы данных называют еще созданием внутренней схемы. Результатом решения этой задачи является скрипт для создания таблиц и индексов, что составляет первоначальный прототип физической модели базы данных.
Таким образом, физическая модель реляционной базы данных есть такое представление отношений базы данных и связей между ними, которое воплощено в последовательность команд SQL. Выполнение этой последовательности команд создает конкретную базу данных и ее объекты.
Одной из основных задач проектировщика данных при создании физической модели реляционной базы данных является превращение логических отношений базы данных в таблицы базы данных.
Элементарной подзадачей является создание таблицы базы данных. Таблицы в реляционных СУБД1 состоят из одной или более колонок или полей. Колонки представляют собой поименованные ячейки в записи, которые содержат значения. Колонки определяются посредством спецификации, которая определяет формат колонки и ее характеристики, задаваемые с помощью ограничений. Определение таблицы задается командой CREATE TABLE.
Создание первоначальной внешней схемы
Однако, если руководителем ИТ-проекта принято решение о разработке внешней схемы, проектировщик должен создать первоначальный вариант внешней схемы.Для того чтобы создать внешнюю схему для новой базы данных, проектировщику базы данных необходимо начать с создания так называемых зеркальных представлений. Такое представление разрабатывается для каждой базовой таблицы внутренней схемы и включает все колонки этой таблицы, т.е. является полным зеркальным отображением базовой таблицы. Типичным требованием к таким представлениям является требование явного именования колонок представления, в противном случае приложениям может потребоваться модификация, если имена колонок будут изменены. Далее эти представления используются разработчиками и пользователями для доступа к базовой таблице.
Дополнительные представления могут быть созданы для приложений, которые выполняют так называемые типовые запросы к базам данных. Под типовым запросом здесь понимается запрос, который выполняется с высокой частотой использования либо одним пользователем, либо группой пользователей. Такое представление проектировщик базы данных может разработать, если требования к обработке данных задокументированы в спецификациях к базе данных.
Представления для эпизодических пользователей базы данных также могут быть созданы, если их требования к данным подробно описаны.
Создавать внешнюю схему наиболее удобно параллельно с внутренней, по мере того как создаются базовые таблицы. Решение о том, как проектировщик базы данных будет создавать первоначальную внешнюю схему, является его прерогативой.
Пример. Для нашей учебной базы данных первоначальная внешняя схема может выглядеть следующим образом:
CREATE VIEW DEPARTAMENT_V AS SELECT DEPNO, DNAME, LOC, MANAGER, PHONE FROM DEPARTAMENT;
CREATE VIEW EMPLOYEE_V AS SELECT EMPNO, ENAME, LNAME, DEPNO, SSECNO, JOB, AGE, HIREDATE, SAL, COMM, FINE FROM EMPLOYEE;
CREATE VIEW PROJECT_V AS SELECT PROJNO, PNAME, BUDGET FROM PROJECT;
CREATE VIEW PERSPROJ AS SELECT ENAME, JOB, PNAME FROM EMPLOYEE, PROJECT, EMPL_PROJ WHERE EMPLOYEE.EMPNO= EMPL_PROJ.EMPNO AND EMPL_PROJ.PROJNO=PROJECT.PROJNO;
Проектировщик базы данных в данном случае решил создать зеркальные представления для базовых таблиц, представляющих сущности предметной области. При этом он использовал суффикс _V в именах представлений, для того чтобы указать, что эти представления зеркально отображают поля базовой таблицы с именем без суффикса.
Кроме этого, он добавил представление, позволяющее получать информацию о служащих и выполняемых ими проектах, которая включает связывающую таблицу для этого отношения со степенью связи "многие-ко-многим".
В этом разделе мы рассмотрели механизм представлений реляционной базы данных. Представления как объекты базы данных занимают немного физического пространства в словаре базы данных, но обеспечивают функциональность базы данных на уровне таблиц. Помимо прочего они позволяют скрывать от пользователей информацию о физической структуре таблиц базы данных, что повышает безопасность эксплуатации базы данных в целом. Представления являются в реляционных базах данных основным механизмом для построения внешней схемы базы данных.
Ниже приведены рекомендации проектировщикам баз данных по созданию представлений в типичной реляционной базе данных.
Литература: [14], [15], [20], [45].
Создание представлений
СУБД предоставляет вам возможность создавать представления или так называемые виртуальные таблицы. Виртуальная таблица, или представление, является таблицей, которой физически нет в базе данных, но которая существует в представлении пользователя о логической структуре данных. Виртуальная таблица не содержит фактических данных, а реализуется как запрос к существующим таблицам базы данных. Определение представления хранится в словаре базы данных. Виртуальную таблицу можно рассматривать как поименованный запрос, который порождает таблицу для использования другими запросами. Таким образом, представление, или виртуальная таблица, - это поименованный запрос на выборку данных из одной или нескольких базовых таблиц, определение которого сохраняется в словаре базы данных.Примечание. Далее в тексте термины "представление" и "виртуальная таблица" будут употребляться на равных правах.
Виртуальные таблицы используются в основном для реализации внешних схем данных (точек зрения пользователя). Они упрощают доступ к данным за счет замены сложных запросов более простыми запросами, обеспечивают независимость и защиту данных. Виртуальная таблица является объектом реляционной базы данных.
Для создания виртуальных таблиц в SQL предназначена команда CREATE VIEW. Пусть вам требуется регулярно просматривать списки служащих по отделам. Тогда вы можете использовать виртуальную таблицу
CREATE VIEW EMPLIST AS SELECT DEPNO, EMPNO, ENAME, JOB FROM EMPLOYEE GROOP BY DEPNO, EMPNO, ENAME, JOB;
Как видите, виртуальная таблица является средством именования часто используемых команд SELECT. Как известно, результат выполнения команды SELECT является таблицей. Виртуальная таблица, при создании которой используется предложение GROUP BY, иногда называется групповым представлением (grouped view)
Как только промежуточная таблица получает имя, к ней можно делать запрос. Например, выполнить команду
SELECT * FROM EMPLIST WHERE DEPNO=10;
которая дает список сотрудников 10-го подразделения.
Виртуальные таблицы можно определять с помощью других виртуальных таблиц.
Однако во многих реализациях SQL представления имеют сильные ограничения на выполнение операций обновления данных над ними. Некоторые СУБД не разрешают в определении представления использовать предложение ORDER BY. В некоторых диалектах SQL недопустимо выполнение обновлений на виртуальных таблицах, определенных на нескольких базовых таблицах, а также содержащих предложения GROUP BY, HAVING, опцию DISTINCT и функции агрегирования. Такие представления используются только для чтения. Например, в СУБД SQLBase представление используется только для чтения (read-only view), если в определяющей команде SELECT:
Иногда запрещается использовать и подзапросы.
В противном случае представление считается обновляемым представлением (updatable view). Для обновляемых представлений предусмотрена опция WITH CHECK OPTION. Когда она указана, любая вставка и обновление через данное представление будет выполняться только, если представление отвечает своему определению (данные в таблице могут быть изменены непосредственно). В противном случае такой проверки не делается. Если представление предназначено только для чтения или применяет подзапрос, то данная опция не должна использоваться.
Команда ALTER TABLE с такими же ограничениями также выполнима на виртуальных таблицах.
Создание связывающих таблиц для
Отношения "многие-ко-многим", как уже упоминалось в предыдущих лекциях, не могут быть в подавляющем большинстве случаев непосредственно реализованы в реляционных базах данных без создания промежуточных таблиц, иначе называемых связывающими таблицами (junction tables). Связывающая таблица является базовой таблицей (дочерней) базы данных, которая представляет отношение связи между двумя таблицами (родительскими), находящимися в отношении "многие-ко-многим". Процедура представления отношения "многие-ко-многим" с помощью связывающей таблицы на языке проектировщика базы данных носит название разрешение взаимосвязи (или связи) "многие-ко-многим". Эта задача может быть частично решена на стадии логического проектирования реляционной базы данных. На этой стадии требуется аккуратное воплощение решения этой задачи в операторах SQL.Алгоритм задачи разрешения взаимосвязи следующий:
Этот алгоритм решает задачу разрешения отношения "многие-ко-многим". Однако можно подумать об атрибутах (колонках), которые могут существовать у связи (ее представляет связывающая таблица). Такие колонки могут быть помещены в связывающую таблицу. Это могут быть колонки, общие для связываемых таблиц.
Рассмотрим пример. Используемая схема базы данных учебного примера не позволяет использовать одного служащего в нескольких проектах (реализовано отношение "много (служащих) к одному (проекту)").
На практике обычно каждый служащий работает над несколькими проектами (отношение "многие-ко-многим"). Чтобы реализовать такое отношение, необходимо модернизировать структуру физической базы данных. Определим отношение "многие-ко-многим" через создание новой таблицы EMP_PRJ
CREATE TABLE EMP_PRJ ( EMPNO integer NOT NULL, PROJNO char(8) NOT NULL, WORKS number, PRIMARY KEY (EMPNO, PROJNO), FOREIGN KEY (EMPNO) REFERENCES EMPLOYEE, FOREIGN KEY (PROJNO) REFERENCES PROJECT, );
которая будет служить для распределения служащих по проектам. В этой таблице каждому служащему отвечает столько строк, сколько проектов он выполняет. Схема базы данных примет теперь вид как на рис. 9.1. Колонка PROJNO таблицы EMPLOYEE при этом потеряла свой семантический смысл. Ee следует удалить из таблицы EMPLOYEE за ненадобностью.
Рис. 9.1. Логическая структура учебной базы данных после разрешения отношения "многие-ко-многим"
Как работать с ограничением внешнего ключа, будет показано далее в соответствующем подразделе.
CREATE TABLE DEPARTAMENT ( DEPNO integer NOT NULL, DNAME char(20), LOC char(20), MANAGER char(20), PHONE char(15), PRIMARY KEY (DEPNO) определение первичного ключа );
CREATE TABLE EMPLOYEE ( EMPNO integer NOT NULL, ENAME char(25), LNAME char(10), DEPNO int, SSECNO char(10), JOB char(25), AGE date, HIREDATE date NOT NULL WITH DEFAULT, SAL dec(9,2), COMM dec(9,2), FINE dec(9,2), PRIMARY KEY (EMPNO) ); CREATE TABLE PROJECT ( PROJNO char(8) NOT NULL, PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) );
CREATE TABLE EMP_PRJ ( EMPNO integer NOT NULL, PROJNO char(8) NOT NULL, WORKS number, PRIMARY KEY (EMPNO, PROJNO), FOREIGN KEY (EMPNO) REFERENCES EMPLOYEE, FOREIGN KEY (PROJNO) REFERENCES PROJECT );
Таким образом, в результате описанных выше действий был получен скрипт для создания базовых таблиц учебного примера. Этот скрипт можно выполнить, чтобы создать базовые таблицы. Но обычно проектировщики баз данных не спешат, а продолжают далее совершенствовать полученный скрипт.
Будем считать разработанный скрипт первой итерацией в создании внутренней схемы базы данных - создании базовых таблиц.
Дальнейшими задачами проектировщика базы данных будут задачи усовершенствования и доработки разработанного скрипта в следующих направлениях:
Первые три направления деятельности носят опциональный характер и определяются особенностями конкретного ИТ-проекта и вкусами руководителя данного проекта, а также требованиями к базе данных и бизнес-правилами предметной области, если они представлены в исходной документации. Часто, особенно при использовании объектно-ориентированной парадигмы в разработке приложений базы данных, эти три направления деятельности проектировщика базы данных могут быть переданы разработчикам приложений базы данных. Поэтому мы подчеркиваем здесь их необязательный характер. Как может решать такие задачи проектировщик базы данных, будет рассмотрено в других разделах этой лекции. Четвертое направление деятельности очень желательно. Его следует выполнять, если априорно имеются данные о возможном поведении данных в системе во времени. Обычно борьба за производительность относится к задачам обратного влияния, когда становятся известными параметры эксплуатации системы. Это направление деятельности будет рассматриваться в двух последу ющих лекциях.
Последнее направление деятельности носит обязательный характер для обеспечения функционирования базы данных, эта задача в большей степени является задачей администратора базы данных - лица, ответственного за эксплуатацию базы данных в организации.
Как решаются такие задачи, будет рассмотрено в следующей лекции.
Ниже приведен типичный синтаксис некоторых команд SQL.
Синтаксис оператора CREATE TABLE:
CREATE TABLE имя_таблицы (имя_колонки тип_данных [NOT NULL | NOT NULL WITH DEFAULT] [, имя колонки ѕ] [PRIMARY KEY (имя_колонки [,имя_колонки ѕ]] [FOREIGN KEY [имя_ключа] (имя_колонки [, имя_колонки ѕ ]) REFERENCES имя_таблицы_родителя [ON DELETE [RESTRICT | CASCADE | SET NULL]]] ) [IN [имя_базы_данных] имя_области_табличного_пространства | IN DATABASE имя_базы_данных] [PCTFREE целочисленная_константа]
Примечание. Здесь и ниже опции операторов SQL, которые не объясняются в настоящем разделе книги, поясняются далее, там, где логика изложения требует их детального обсуждения. Подчеркивание ключевого слова обозначает значение, принятое по умолчанию.
Синтаксис оператора CREATE INDEX:
CREATE [UNIQUE] [CLUSTERED HASHED] INDEX имя_индекса ON имя_таблицы (имя_колонки [ASC | DESC] [, имя_колонки ѕ]) [PCTFREE целочисленная_константа] [SIZE целочисленное_значение [ROWS | BUCKETS]]
Создание таблиц с ограничениями ссылочной целостности
Для создания таблиц с поддержкой ограничений ссылочной целостности в SQL предназначены команды CREATE TABLE и команда ALTER TABLE. Таким образом, вы имеете два основных способа для поддержки ссылочной целостности в реляционной базе данных:В предыдущих разделах уже было показано использование предложения PRIMARY KEY команды CREATE TABLE. Пример использования предложения FOREIGN KEY команды CREATE TABLE продемонстрируем на примере создания таблицы для иерархии "руководитель-подчиненный":
CREATE TABLE MANAGEMENT ( MANAGNO INT NOT NULL, EMPNO INT, JOB INT, PRIMARY KEY (MANAGNO), FOREIGN KEY fnkey (EMPNO) REFERENCES EMPLOYEE ON DELETE CASCADE);
CREATE UNIQUE INDEX ndxmng ON MANAGEMENT(MANAGNO);
fnkey - имя внешнего ключа, предложение REFERENCES, связанное с предложением FOREIGN KEY, определяет имя таблицы-родителя, предложение ON DELETE определяет правило удаления записей в связанных таблицах. Каждое правило удаления соответствует определенной взаимосвязи между объектами реляционной базы данных (т. е. предметной области).
Правила удаления используются только в определении внешнего ключа. Обычно СУБД в соответствии со стандартом SQL поддерживает три правила:
Для самоссылающихся таблиц используется только правило CASCADE. Правило RESTRICT препятствует удалению строки в таблице-родителе, если ей соответствуют какая-либо строка в таблице-потомке. Правило CASCADE определяет, что, когда строка в таблице-родителе удаляется, то все связанные с ней строки в таблице-потомке автоматически должны быть удалены. Правило SET NULL определяет, что, когда строка в родительской таблице удаляется, значения внешнего ключа во всех строках таблицы-потомка должны автоматически устанавливаться в нуль-значение.
Применение команды ALTER TABLE продемонстрируем на примере создания отношения "родитель-потомок" для таблиц DEPARTAMENT и EMPLOYEE учебной базы данных. Первичные ключи и индексы для этих таблиц уже созданы. Создадим внешние ключи (в таблицу DEPARTAMENT должна быть добавлена колонка EMPNO).
ALTER TABLE DEPARTAMENT FOREIGN KEY EMP_DEP (EMPNO) REFERENCES EMPLOYEE ON DELETE RESTRICT;
Для того, чтобы удалить первичный или внешний ключ таблицы, необходимо использовать предложение DROP команды ALTER TABLE.
Создание таблиц
С точки зрения стандарта SQL-92, таблицы подразделяются на три категории.Физическая модель реляционной базы данных содержит базовые таблицы. Для определения и создания таблиц в SQL-92 предусмотрена команда CREATE TABLE, которая определяет имя таблицы, имена и физический порядок колонок для нее, тип каждой колонки, а также некоторые указания для СУБД, такие как определение первичного или внешнего ключа, требования на запрет неопределенных значений в колонке таблицы и т.п. Полный формат команды CREATE TABLE для каждой СУБД приводится в соответствующем документе с названием типа "Справочное руководство по SQL для СУБДѕ".
Ссылочная целостность
В реляционной теории концепция ссылочной целостности была предложена в 1976 году П. Ченом. В рамках этой концепции все отношения реляционной базы данных разделяют на два класса: объектные отношения и связные отношения. Объектное отношение предназначено для описания состояния объекта через значения его атрибутов. Ему в физической модели базы данных отвечает базовая таблица. Связное отношение предназначено для фиксации связей между объектами через значения ключевых атрибутов объектов. Ему в физической модели базы данных также может отвечать базовая таблица. Обычно связные отношения поддерживаются в физической модели базы данных через ограничения первичного и внешнего ключей.Ссылочная целостность означает, что все связи между отношениями замкнуты, т.е. все ссылки между отношениями допустимы и нет ссылок на несуществующие объекты (отношения, кортежи). Это предохраняет приложения пользователей от ситуаций, когда изменения в одном отношении не отражаются в других, связанных с ним.
Допустимость ссылки еще не означает ее корректность. Так, в учебной базе данных вы можете приписать служащему в таблице EMPLOYEE несуществующий номер отдела. Однако значение номера отдела в этой таблице должно быть согласовано с соответствующим значением в таблице DEPARTAMENT. Поддержка ссылочной целостности будет гарантировать лишь то, что такой отдел существует в таблице DEPARTAMENT. При этом вставка служащего с неправильным номером отдела будет заблокирована. Однако правильность списка сотрудников отдела не контролируется. Допустимая ссылка еще не означает ее правильность.
Иными словами, ссылочная целостность задает ограничения на связи между отношениями реляционной базы данных за счет управления значениями некоторых атрибутов взаимосвязанных отношений. Ограничения ссылочной целостности называются еще правилами ссылочной целостности.
Такие ограничения (в виде бизнес-правил) определяются при анализе предметной области базы данных системным аналитиком и, следовательно, субъективны. Например, для нашей учебной базы данных можно сформулировать следующие правила ссылочной целостности:
В настоящее время большинство промышленных реляционных СУБД имеют встроенный механизм поддержки ссылочной целостности. Таким образом, вам не нужно писать код для поддержки ссылочной целостности в своем приложении, СУБД делает эту работу сама.
Механизм поддержки ссылочной целостности основывается на использовании следующих понятий:
Виртуальные таблицы с соединениями
Если вам необходимо работать с несколькими таблицами как с одной, вы можете создать виртуальную таблицу, объединяющую информацию из нескольких таблиц. Пусть вам нужна информация о служащих и выполняемых проектах, тогда можно создать следующую виртуальную таблицу:CREATE VIEW PERSPROJ AS SELECT ENAME, JOB, PNAME FROM EMPLOYEE, PROJECT WHERE EMPLOYEE.PROJNO=PROJECT.PROJNO;
Выполняя команду
SELECT * FROM PERSPROJ;
вы получите необходимую вам информацию. При этом вам не нужно помнить, что данные хранятся в двух таблицах. Даже если будет изменена структура базы данных, не затрагивающая колонки из виртуальной таблицы, вы этого не заметите.
Можно выполнять и более сложные запросы на виртуальных таблицах. Допустим, что вам нужен список руководителей по проектам, тогда вы можете выполнить
SELECT ENAME, PNAME FROM PERSPROJ WHERE JOB='руководитель';
С виртуальными таблицами используется предложение WITH CHECK OPTION. При этом каждая вставка или обновление будет проверяться на соответствие определению виртуальной таблицы и будет отвергаться, если такого соответствия не будет. В противном случае такой проверки не делается.
Пусть вам нужно иметь информацию о текущих проектах. Тогда можно определить виртуальную таблицу (предварительно определив поле START_DATE в таблице PROJECT и установив его значения) как
CREATE VIEW CURPROJ AS SELECT * FROM PROJECT WHERE START_DATE < SYSDATE WITH CHECK OPTION;
Колонка START_DATE при обновлении будет проверяться на соответствие текущей дате. Это предложение справедливо только для обновления данных в колонках базовых таблиц, для которых создана такая виртуальная таблица. Если виртуальная таблица только для чтения или при его создании используется подзапрос, то WITH CHECK OPTION не должно указываться.
Задание ограничений NOT NULL на значения колонок
При определении спецификаций колонок таблиц проектировщик базы данных должен рассмотреть ограничения, которые могут быть наложены на значения колонок. В реляционных СУБД этих ограничений предусмотрено достаточно много. Здесь мы остановимся на одном из главных ограничений такого рода - это обязательность присутствия значения в колонке. Такое ограничение на значение колонки называется NOT NULL ограничением.Предопределенное значение колонки, равное NULL, означает, что в данный конкретный момент для данной конкретной строки (экземпляра сущности предметной области) значение не определено, или не известно, или отсутствует. Проектировщику базы данных необходимо идентифицировать возможность колонки принимать NULL-значения, т.к. пользователи могут иметь проблемы при использовании таких колонок. Примером этой проблемы может служить ситуация, в которой пользователю требуется выполнить соединение двух таблиц по колонкам, имеющим NULL-значения. При выполнении таких соединений любые строки, которые содержат NULL-значения в колонках соединения в любой из таблиц, не будут показаны в результирующей выборке для запроса. Подобная потеря данных может привести к тому, что пользователь получит неправильную выборку на запрос, особенно если ему необходимо видеть все строки хотя бы одной из таблиц.
Примечание. Одним из способов решения определенной выше проблемы является использование внешних соединений.
При назначении NULL-значений колонкам проектировщику базы данных необходимо принимать во внимание следующие факторы.
далее.)
CREATE TABLE DEPARTAMENT ( DEPNO integer NOT NULL, DNAME char(20), LOC char(20), MANAGER char(20), PHONE char(15), PRIMARY KEY (DEPNO) определение первичного ключа );
CREATE TABLE EMPLOYEE ( EMPNO integer NOT NULL, ENAME char(25), LNAME char(10), DEPNO int, SSECNO char(10), PROJNO char(8), JOB char(25), AGE date, HIREDATE date NOT NULL WITH DEFAULT, SAL dec(9,2), COMM dec(9,2), FINE dec(9,2), PRIMARY KEY (EMPNO) );
CREATE TABLE PROJECT ( PROJNO char(8) NOT NULL, PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) );
Основы проектирования реляционных баз данных
Денормализация методом "разделяй и властвуй"
Денормализация методом "разделяй и властвуй" - это процесс разбиения нормализованной таблицы на две и более таблиц и создание между ними отношения "один к одному" с целью устранения дополнительных операций ввода/вывода или по техническим причинам.Использование этого приема носит причины технического характера. Во многих СУБД таблица не может иметь больше одного столбца типа LONG или LONG RAW. Допустим, что у вас есть таблица Films и нужно сохранить и окончательный вариант фильма (LONG), и вариант, который отсняли с множеством дублей (LONG RAW). Из-за вышеупомянутого ограничения в одной таблице это сделать нельзя, поэтому один из кодов нужно разместить в отдельной таблице. Проектировщику базы данных не остается ничего другого как разбить таблицу на две.
Иногда лучше вынести столбец LONG в отдельную таблицу, даже если вышеупомянутое ограничение не действует. Рассмотрим таблицу, строки которой содержат в начале ключевые колонки, потом неключевые колонки, а в конце - колонку типа LONG. Предположим, что в большинстве строк столбец LONG содержит данные. Если нет индексов по неключевым столбцам, то при выполнении запросов по любому из этих столбцов СУБД обычно будет осуществлять полное сканирование таблицы. При этом из-за наличия в таблице столбца LONG понадобятся дополнительные операции ввода/вывода.
Чтобы устранить эту проблему, разделите таблицу так, как показано на рис. 10.5.
Рис. 10.5. Выделение колонки LONG в отдельную таблицу
Во многих СУБД таблица не может иметь более 254 столбцов, и если предложить таблицу с большим числом столбцов, то также возникнет причина для разделения такой таблицы на две. Обычно такие таблицы могут понадобиться только в следующих случаях:
Согласно мнению известного специалиста в области проектирования реляционных баз данных Д. Энсора, "Хорошей мерой степени нормализации является число столбцов на таблицу. Эмпирическое правило гласит, что очень немногие первичные ключи имеют более двадцати действительно зависимых от них атрибутов".
Денормализация методом слияния таблиц
Денормализация методом слияния таблиц - это процесс объединения одной или более нормализованных таблиц с целью устранения операций соединений или уменьшения в некоторых случаях числа операций вставки.Возникает резонный вопрос: после того как мы вложили столько сил в нормализацию структур данных и разбивку сущностей, нам предлагается начать слияние таблиц? Фактически слияние оправдано в очень немногих случаях.
Один из примеров обоснованного применения слияния - наличие повторяющейся группы, которая гарантированно состоит из фиксированного числа элементов. Хорошими кандидатами на такое объединение являются таблицы со строкой для каждого месяца года или каждого дня недели. Единственный случай, где фиксированные группы надежны, - это когда они соответствуют абсолютно постоянным вещам, например дням недели.
Будет ли какое либо преимущество от такого слияния заранее сказать трудно. Подход к денормализации должен определяться требованиями к обработке данных.
Альтернатива данному способу денормализации - физическое размещение таблиц в кластере (например, как в СУБД Oracle). Это позволяет хранить рядом строки логически связанных отдельных таблиц.
Таким образом, на практике денормализация представляет собой набор приемов преобразования таблиц с целью повышения производительности обработки запросов. С точки зрения реляционной теории мы как бы не принимаем в рассмотрение наличие некоторых функциональных зависимостей в таблицах. Основным критерием проведения денормализации нормализованных таблиц являются требования к обработке данных. В реляционных базах данных следует избегать неоправданной денормализации таблиц.
Длинные строки в таблицах хэширования
Во многих реляционных СУБД поддерживаются так называемые хэш-кластерные индексы (clustered hashed index). Такие объекты правильнее называть таблицами хэширования, а не индексами. Таблица хэширования представляет собой таблицу реляционной базы данных, доступ к строкам которой осуществляется с помощью преобразования ключа. Значения колонок, которые объявлены ключевыми, преобразуются в позиции строк таблицы (и при их вставке там и размещаются) - хэшируются. Такую функцию называют хэш-функцией. Ключ таблицы, который подвергается преобразованию, называется хэш-ключом. Данные, которые обрабатываются таким образом, размещаются в специальных таблицах, называемых еще хэш-кластерами или просто хэш-таблицами. В настоящем курсе предполагается, что проектировщику известны общие методы организации физического доступа к данным, поэтому мы не будем детально обсуждать вопрос, как устроены такие таблицы.Отметим только, что хэширование является очень эффективным методом доступа по первичному ключу к записи за один доступ. Если значения ключа равномерно распределены, то в среднем это будет так. В противном случае производительность доступа будет резко падать из-за коллизий, т.е. случая, когда для двух различных значений первичного ключа хэш-функция дает одинаковые числа, т.е. позиции записи. В худшем случае придется просканировать всю таблицу, чтобы получить одну запись!
Несмотря на то, что построены динамические таблицы хэширования (изменяющие свой размер во время существования), в большинстве СУБД поддерживаются статические таблицы хэширования, размер которых определяется при их создании. В большинстве случаев таблица хэширования формируется случайным образом по отношению к порядку следования значений ключа, хотя известны функции преобразования ключа, которые поддерживают лексикографический порядок на значении ключа таблицы.
Хэш-индекс обычно применяется, если ключ полностью представлен в предложении WHERE и используется операция равенства для колонок ключа. Нас интересует проблема увеличения производительности в хэш-таблицах, когда длина строки превышает размер физической страницы на жестком диске.
Чтобы лучше понять проблему, рассмотрим, как определяется хэш-таблица в SQL.
Такая таблица создается при помощи команды, например
CREATE CLUSTERED HASHES INDEX CHXNAME ON EMPLOYEE (EMPNO) SIZE 2000 ROWS;
Предложение SIZE задает вероятное количество строк в индексе, а ROWS определяет число строк для хранения индекса. Размер можно задавать в блоках (BUCKETS). Таким образом, по значению первичного ключа адресуется блок, содержащий целое число строк, или строка, если ее размер сопоставим с размером физического блока. В последнем случае считается, что блок содержит одну строку.
Для таблицы хэширования определяется параметр "число строк на странице" (rows per page) или "кластеризация страницы" (page clustering), или коэффициент блокировки, равный
Как видно из определения таблицы хэширования, размер строки и размер физического блока должны быть согласованы. Проблема длинной строки в таблице хэширования состоит в том, что если строка занимает несколько блоков, то возрастает частота коллизий и вместо одного физического доступа для получения строки требуется 4-6, что уже сопоставимо с использованием индексов другого типа.
Цель разбиения таблицы хэширования состоит в том, чтобы попытаться достигнуть такого значения параметра blocking factor (коэффициент блокировки), которое содержало бы по крайней мере как можно больше строк, которые будут выбираться вместе в большинстве транзакций к этой таблице в базе данных.
Поскольку в современных СУБД размер физического блока фиксирован для каждой операционной платформы, то единственным способом влияния на величину этого параметра является подгонка размера строки. Если нельзя пересмотреть спецификацию типов колонок таблицы и свести их размеры до минимума, то единственной возможностью выбрать подходящий коэффициент блокирования является разбиение таблицы хэширования.
Горизонтальное разбиение таблиц
На практике горизонтальное разбиение применяется для изоляции одной группы строк таблицы от другой, когда такие группы строк редко используются в одной транзакции. Наиболее типичный пример, когда этот метод оказывается полезным, есть изоляция текущих данных от архивных данных. Рассмотрим систему обработки заказов. Менеджеры и продавцы работают с текущими заказами. Обработка выполненных заказов (архивные данные) выполняется при подготовке разного рода отчетов. Даже если готовится ежедневный отчет с использованием архивных данных, то в организациях среднего размера частота использования текущих данных все равно превышает частоту использования архивных данных на 2-3 порядка, а отношение объема текущих данных к архивным данным может составлять менее 0,001.Одним из практических критериев в данном случае может служить классическое правило 80-20. Если активно работают с 20% данных, то, вероятнее всего, остальные 80% можно перенести в архивную таблицу.
Пример. Для нашей учебной базы данных таблицей - кандидатом на такое горизонтальное разбиение является таблица PROJECT, поскольку в ней имеются архивные данные - выполненные проекты. Предположим, что число выполненных проектов в год в организации где-то около 1000. Данные в таблице нужно хранить 10 лет (10000). Средняя продолжительность проекта равна 2 месяцам, т.е. число незавершенных проектов в каждый момент времени не превышает 200. Через 5 лет отношение числа текущих проектов к архивным проектам достигнет 0,04. Следовательно, проектировщик данных может рассмотреть вопрос о горизонтальном разбиении этой таблицы.
CREATE TABLE PROJECT ( PROJNO char(8) NOT NULL, PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) );
CREATE TABLE PROJECT_OLD ( PROJNO char(8) NOT NULL, PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) );
А для совместного использования двух этих таблиц предусмотреть представление
CREATE VIEW ALL_PROJECT AS SELECT * FROM PROJECT UNION SELECT * FROM PROJECT_OLD; Замечание. Далее под исходной таблицей понимается и сама таблица, и то, что от нее осталось после разбиения.
Методы реализации денормализации: Разбиение таблиц базы данных
Разбиение (splitting) таблиц является одним из общих методов денормализации, который применяется в физическом проектировании реляционных баз данных. Разбиение таблиц бывает двух видов - вертикальное разбиение и горизонтальное разбиение.Вертикальное разбиение является процессом перемещения некоторых колонок таблицы в другую новую таблицу, которая имеет тот же первичный ключ, что и исходная таблица. Горизонтальное разбиение является процессом перемещения некоторых строк одной таблицы в другую новую таблицу, которая имеет такую же внутреннюю структуру, что и исходная таблица.
Основные причины разбиения таблицы: либо существуют некоторые проблемы с производительностью запросов на этой таблице, либо непересекающиеся подмножества строк таблицы имеют значительное различие в производительности обработки. Т.е. подмножества строк таблицы редко встречаются в одном и том же запросе.
Нисходящая денормализация
Рассмотрим принципы денормализации на уровне логической модели реляционной базы данных. Нисходящая денормализация предлагает перенос атрибута из одной (родительской) сущности в подчиненную (дочернюю) сущность. Из рисунков 10.1 и 10.2 видно, что в денормализованной логической модели мы переместили фамилию клиента из сущности Customer (Клиент) в сущность Order (Заказ). Что дает введение избыточности (перенос атрибута) в данном случае? Единственный выигрыш заключается в том, что мы исключаем операцию соединения, если захотим вместе с заказом увидеть фамилию клиента.
Рис. 10.1. Сущности Customer и Order до денормализации
Рис. 10.2. Сущности Customer и Order после денормализации
Таким образом, нисходящая денормализация - это процесс введения избыточных колонок в подчиненных таблицах с целью устранения операций соединения.
Однако устранение соединений посредством нисходящей денормализации редко оправдывает затраты на сопровождение дублирующей колонки в таблице ORDER. Такие соединения, как правило, не являются глобальной проблемой, а выполнение нисходящей денормализации может привести к возникновению дорогостоящих каскадных обновлений, дающих небольшую реальную выгоду. Например, если клиент меняет фамилию, то нам приходится обновлять все заказы, чтобы отразить это изменение. А нужно ли это делать? Следует ли обновлять старые заказы, которые выполнены или закрыты? Если бы не была проведена денормализация, то эти вопросы никогда бы и не возникли.
Нисходящая денормализация оправдана лишь в приложениях, где необходимо устранять операции соединения таблиц. Это имеет место в базах данных большого объема, таких как хранилища данных. При этом проблемы с каскадными обновлениями не возникает потому, что данные в хранилищах данных - архивные.
Понимание типа приложений базы данных
Прежде чем обсуждать основные типы приложений баз данных, уточним термины транзакция и запрос. В теории баз данных, вообще говоря, под транзакцией понимают одну из команд SQL - SELECT, INSERT, UPDATE, DELETE. Однако в зависимости от типа приложений термин транзакция трактуется более свободно как элементарная логически завершенная единица работы (так называемая бизнес-транзакция), которая может включать несколько команд вставки, удаления или модификации. В зависимости от того, какие команды SQL используются, транзакции разделяют на транзакции только для записи (write-only), только для модификации (modify-only), только для чтения (read-only), только для удаления (delete-only). Транзакции только для чтения называют запросом.Исходя из такого деления транзакций по типам обработки с учетом частоты транзакций каждого типа, можно выделить три основных классических типа приложений баз данных:
Существенным фактором для этих систем является отношение запросов к транзакциям обновления. Классическим примером таких систем является обслуживание базы данных продукции организации.
Можно выделить еще несколько типов приложений, появившихся в последние два десятилетия.
Проектировщик базы данных должен оценить тип приложений, для которых он разрабатывает базу данных. Это позволит ему оценить (в случае отсутствия явно прописанной в документации информации):
Далее эта информация понадобится проектировщику базы данных для анализа транзакций.
Понятие о денормализации
Начиная с этого раздела мы переходим к рассмотрению методик настройки физической структуры реляционной базы данных с целью удовлетворения требования к производительности базы данных. Эти методики представляют собой набор рекомендаций и эвристических правил по изменению физической структуры базы данных, которая была получена проектировщиком базы данных в результате создания первой итерации физической модели базы данных. Ясно, что использование этих методик носит опциональный характер.В этом разделе будут описаны различные типы денормализации и методы реализации этого процесса. Кроме того, мы рассмотрим, как использовать для поддержки денормализации триггеры и как обеспечить целостность данных, не прибегая к созданию дополнительного кода.
Под денормализацией понимают процесс достижения компромиссов в нормализованных таблицах посредством намеренного введения избыточности в целях увеличения производительности.
В большинстве случаев необходимость денормализации становится очевидной лишь на этапе проектирования модуля. Другими словами, обычно нельзя принять решение о денормализации на основании одной только модели данных. Когда проектировщик принимает решение о денормализации, то должен господствовать здравый смысл. Обычно стараются найти в приложении базы данных критичные процессы и принимать решения о денормализации в основном в пользу этих процессов. Критичные процессы обычно определяют по высокой частоте, большому объему, высокой изменчивости или явному приоритету. Если проектировщик базы данных прописал все транзакции базы данных, то он, вероятно, сможет определить наличие таких критических процессов.
Замечание. Использовать денормализацию только для упрощения SQL-запросов при обращении к базе данных является неправильным решением. Если вы хотите упростить SQL-запросы на уровне приложения или пользователя, то, наверное, лучше использовать представления, а не вводить избыточность. Чтобы повысить производительность запроса, можно ввести индексы. Как оптимизировать запрос, будет рассмотрено в последней лекции этого курса.
Как правило, денормализация уменьшает время запроса за счет DML-операций. Денормализацию следует рассматривать как расширение нормализованной модели данных, которое повысит производительность запросов. При принятии решения о денормализации определите, что является наиболее важным для приложения - избыточность данных или высокая производительность. Если проектировщик базы данных ведет журнал проектирования (некоторый внутренний документ произвольной формы, в котором фиксируются все принятые в процессе проектирования базы данных решения), то в него необходимо занести обоснованное решение о денормализации. Помните, что кроме денормализации существуют и другие пути повышения производительности. Денормализацию таблиц можно выполнять как на уровне логической модели данных, так и на уровне физической модели.
Разбиение таблиц и ссылочная целостность
Если до разбиения таблица была нормализована, то первичные ключи будут идентичны для таблиц, полученных в результате разбиения. Следовательно, взаимосвязи новых таблиц с другими таблицами базы данных могут остаться такими же, как и с первоначальной таблицей. Однако проектировщик базы данных должен рассмотреть как действие правил удаления для исходной таблицы, так и участие новой таблицы в существующих взаимоотношениях ссылочной целостности, когда будет решать вопрос об определении поддержки ссылочной целостности в новых таблицах. В некоторых случаях может быть проще не определять ссылочную целостность вовсе, так как фактическое удаление строк из новой таблицы будет поддерживаться параллельно с исходной таблицей каким-либо программным способом в приложении базы данных.Пример. Для нашей учебной базы данных для разрешения отношения "многие-ко-многим" между таблицами EMPLOYEE и PROJECT была введена связывающая таблица EMP_PRJ, которая имеет ограничения ссылочной целостности с таблицей PROJECT. Но у нас появилась еще таблица PROJECT_OLD.
Предположим, что для реализации проекта организация нанимает сотрудников на временной основе (на время выполнения проекта), и вопрос, кто, какие проекты и когда делал, мало интересует руководство организации. В этом случае взаимосвязь между исполнителями и проектами, которые уже завершены, не интересует руководство, и, следовательно, во внутренней схеме больше ничего менять не нужно. Однако если взаимосвязь между исполнителями и завершенными проектами должна отслеживаться (например, руководство будет изучать вопрос, кто, когда и какой проект делал), ее следует распространить и на таблицу PROJECT_OLD. Для этого достаточно внести ограничение внешнего ключа в таблицу EMP_PRJ, как показано ниже:
CREATE TABLE EMP_PRJ ( EMPNO integer NOT NULL, PROJNO char(8) NOT NULL, WORKS number, PRIMARY KEY (EMPNO, PROJNO), FOREING KEY (EMPNO) REFERENCES EMPLOYEE, FOREING KEY (PROJNO) REFERENCES PROJECT, FOREING KEY (PROJNO) REFERENCES PROJECT_OLD );
При разбиении таблицы, для которой были определены ограничения ссылочной целостности, можно также рассмотреть возможность поддержки ссылочной целостности установлением взаимосвязи "один-ко-одному" в сторону исходной таблицы от новой таблицы. В этом случае новая таблица будет иметь внешний ключ, идентичный первичному ключу таблицы. Если определено каскадное правило удаления для этого внешнего ключа, то СУБД будет автоматически удалять строки новой таблицы, когда соответствующая строка исходной таблицы будет удалена, хотя управление вставкой строк придется перенести в приложение базы данных.
Пример. Для нашего примера окончательный код может быть следующим:
CREATE TABLE PROJECT ( PROJNO char(8) NOT NULL, PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) );
CREATE TABLE PROJECT_OLD ( PROJNO char(8) NOT NULL, PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) FOREING KEY (PROJNO) REFERENCES PROJECT );
CREATE TABLE EMP_PRJ ( EMPNO integer NOT NULL, PROJNO char(8) NOT NULL, WORKS number, PRIMARY KEY (EMPNO, PROJNO), FOREING KEY (EMPNO) REFERENCES EMPLOYEE, FOREING KEY (PROJNO) REFERENCES PROJECT, );
При принятии решения о разбиении таблицы следует придерживаться следующего алгоритма:
Если СУБД будет управлять ссылочной целостностью для новых таблиц таким же образом, как и для исходной таблицы, в зависимости от ее статуса как дочерней таблицы во взаимосвязи, то вы должны добавить колонку внешнего ключа каждой родительской таблицы во взаимосвязи в новую таблицу, т.е. новая таблица должна содержать ограничение внешнего ключа, идентичное родительской таблице для каждой взаимосвязи.
или
Можно установить связь "один-ко-одному" между новой таблицей и исходной таблицей, определив внешний ключ обратно к исходной таблице тождественным первичному ключу.
Если СУБД будет управлять ссылочной целостностью для новых таблиц таким же образом, как и для исходной таблицы, в зависимости от ее статуса как родительской таблицы во взаимосвязи, то вы должны добавить внешний ключ в каждую дочернюю таблицу исходной таблицы, чтобы идентифицировать эту новую таблицу как дочернюю.
или
Если поступить, как в первой части пункта 3, то новые таблицы не следует объявлять как родительские в других взаимоотношениях. Исходная таблица поддерживает все взаимосвязи, в которых она выступает родителем.
Литература: [7], [20], [23], [42], [45].
Спецификация транзакций
Итак, транзакция базы данных - это логическая единица работы, которая переводит базу данных из одного завершенного состояния в другое завершенное состояние. Под завершенным состоянием базы данных здесь понимается такое состояние данных в базе данных, которое не нарушает целостности этих данных - все данные в таблицах базы данных правильны, а ссылки между таблицами корректны. В дополнение, транзакция группирует операции над данными таким образом, чтобы все обращения к базе данных были успешно завершены или, в случае сбоя, база данных возвратилась в предыдущее завершенное состояние (откат транзакции).Поскольку любая операция изменения данных в базе данных несет в себе потенциальную возможность нарушения целостности данных, необходимо строго определять транзакции и идентифицировать информацию, которая обычно включается в определение транзакции.
Определение транзакции может иметь различные формы. Иногда для определения транзакций используется репозиторий данных CASE-средств проектирования базы данных. Очень часто определение транзакций выполняется посредством текстовых описаний. Независимо от выбранного подхода любое хорошее определение транзакции включает несколько важных элементов. К таким элементам относятся:
Первым шагом в определении транзакции является уникальная идентификация каждой транзакции базы данных. Это можно сделать назначением имени и номера каждой транзакции базы данных. Имена транзакций должны позволять пользователям отличать их друг от друга. Описание транзакций включает перечень операций предметной области, которые выполняются транзакцией. Что касается описания транзакций, то оно должно быть выполнено в терминах предметной области, понятных пользователю. Здесь нужно иметь в виду следующее: а) описание транзакции должно описывать, что транзакция делает для пользователя, а не как она выполняется; и б) описание должно быть понятно пользователю, что не исключает использование технологического жаргона.
Пример. Спецификация транзакции
Номер транзакции: 001
Имя транзакции: Назначить работу служащему.
Описание транзакции: Транзакция проверяет, не назначена ли уже данная работа данному служащему, затем проверяет, располагает ли служащий рабочим временем для выполнения данной работы. Если результаты проверки положительны (данная работа не назначена данному служащему, и служащий располагает временем для ее выполнения), то происходит назначение данной работы данному служащему.
В OLTP-системах большинство транзакций известны заранее, поэтому между спецификацией транзакции и транзакцией базы данных существует взаимно однозначное соответствие. В DSS-системах транзакции часто не известны заранее, и, следовательно, невозможно в принципе описать все транзакции. В этом случае спецификация транзакции лишь в общих чертах описывает транзакции базы данных, поэтому проектировщику базы данных важно уметь предсказать тип транзакций, которые пользователь вероятнее всего будет выполнять в базе данных.
Для каждой транзакции может быть определен характер транзакции как онлайновая транзакция или пакетная транзакция, а также указана ее сложность. Обычно сложность указывается в терминах "высокая", "средняя", "низкая". Эта информация нужна проектировщику базы данных для оценки транзакций базы данных в целом. Количество транзакций той или иной сложности влияет на время проектирования физической модели базы данных - чем больше в базе данных транзакций высокой сложности, тем больше время проектирования физической модели. Сложность транзакции является условной мерой трудоемкости работы проектировщика базы данных при достижении требований производительности базы данных.
Высокая сложность приписывается обычно транзакции, которая имеет две из следующих характеристик:
Низкая сложность приписывается транзакции со следующими характеристиками:
Транзакция со средней сложностью имеет характеристики между нижней и высокой сложностью.
Пример. Спецификация транзакции
Продолжая приведенный выше пример, можем указать следующее:
Характер транзакции: онлайновая транзакция.
Сложность: средняя.
Объем транзакции (Transaction volume statistics) включает обычно два параметра: среднюю частоту транзакции (например, 50 тр./ч) и пиковую частоту транзакции (например, 70 тр./ч). Оценка частотных характеристик транзакций базы данных очень важна для проектирования физической модели базы данных: настройка физической структуры базы данных для транзакций с высокой частотой существенно отличается от настройки ее для транзакции с низкой частотой использования.
Для модернизации существующих систем информация о частотах транзакций может быть представлена во входной документации на основе анализа статистики эксплуатации системы. А вот для вновь создаваемых баз данных такую информацию получить практически невозможно, и приходится пользоваться приблизительными оценками.
Пример. Дополняя наш пример, мы можем указать, что Средняя частота транзакции: до 10 в день. Пиковая частота: 10 в час.
Спецификация транзакции должна включать требования по производительности транзакции. Производительность базы данных в целом складывается из производительности каждой транзакции в отдельности и их распределения во времени. Это очень важная информация для проектировщика данных при решении им задачи настройки физической структуры базы данных. Если проектировщик базы данных не имеет такой информации, он не может решить задачу достижения производительности путем подбора соответствующих конструкций базы данных. Требования по производительности обычно задаются в виде параметра время реакции, т.е. количества секунд, требуемых для выполнения транзакции. Например, во многих банковских системах транзакция для снятия денег со счета клиента не должна занимать более 5 секунд.
Другой формой задания требования на производительность транзакций базы данных является указание их характера и сложности. Например:
В какой форме проектировщик базы данных получит требования на производительность транзакций, сказать сложно. Будет очень хорошо, если он их вообще получит. Это является одним из самых узких мест, как в исходной документации, так и в проектировании физической модели. На практике проектировщики баз данных "отпускают" базу данных в опытную эксплуатацию таким образом, чтобы получить временные характеристики выполнения транзакций и удовлетворить требованиям по производительности в рамках решения задач обратного влияния.
Желательно в спецификации транзакции указать ее относительный приоритет, который показывает, насколько важна настоящая транзакция для предметной области по сравнению с другими. Относительный приоритет транзакции позволяет проектировщику базы данных сгруппировать транзакции по этому параметру, что даст возможность последовательно оценить все транзакции базы данных и их вклад в производительность базы данных.
Далее в процессе создания физической модели данных проектировщик базы данных будет настраивать физическую структуру так, чтобы каждая в отдельности выполнялась быстрее. Выполнение какой-либо транзакции в базе данных с большим приоритетом отрицательно сказывается на производительности других транзакций. Ранжирование транзакций по относительному приоритету позволяет сбалансировать влияние транзакций друг на друга в базе данных в целом.
Задание приоритета транзакций может иметь различные формы.
Обычно такое действие сводится к субъективной оценке в виде числа от 1 до 10.
Каждая спецификация транзакции должна содержать команды SQL, которые задают операции с базой данных. Указание команд SQL в контексте создания физической модели базы данных позволяют оценить время выполнения транзакций (execution time), т.е. фактическое количество секунд, необходимое для завершения транзакции в режиме эксплуатации базы данных. Для проектировщика базы данных этот параметр важен еще и с точки зрения разработки спецификаций модулей приложений базы данных для разработчиков приложений.
Помимо собственно команды языка манипулирования данными, желательно включить некоторый комментарий к каждой команде, в котором указать: а) что команда делает, б) почему это требуется, и в) количество строк в базе данных, которое захватывается командой. Время выполнения команды SQL непосредственно зависит от числа обрабатываемых командой строк. Обычно время выполнения транзакций можно оценить на стадии опытной эксплуатации и тестирования базы данных.
Пример. Продолжая наш пример, можно составить следующую таблицу.
| Select works from project where empno=:1 and works=:2 | Возвращает информацию о назначении данной работы данному служащему. По крайней мере, одна строка возвращается. Число строк, которые могут обрабатываться командой, равно текущему размеру таблицы PROJECT |
| Select works from project where empno=:1 | Возвращает список работ данного служащего, чтобы оценить его загруженность. Число строк, которые могут обрабатываться командой, равно текущему размеру таблицы PROJECT |
| Insert into project empno, works values(:1,:2) | Назначает данного служащего на данную работу, если это необходимо |
Вертикальное разбиение длинных строк
Проблемы с производительностью выполнения запросов на длинных строках таблицы являются наиболее частой причиной для выполнения вертикального разбиения таблицы. Критериями того, что строка является длинной, могут быть:Рассмотрим случай, когда длина строки больше размера физической страницы базы данных. Таблица в этом случае либо имеет слишком много колонок, либо некоторые колонки имеют большую длину. В этом случае СУБД при вставке строки в таблицу будет использовать одну или более дополнительных физических страниц для сохранения строки. Следовательно, при выборке строки из таблицы потребуется больше операций ввода/вывода на число дополнительных физических страниц. Производительность запроса при этом будет ухудшаться. Для увеличения производительности выборки можно разбить таблицу на одну или несколько таблиц с длиной строки подходящего размера.
Метод вертикального разбиения принципиально прост, если вспомнить, что разбиение эквивалентно реляционной операции проекции на таблице. Ясно, что некоторые колонки просто переносятся в новую таблицу так, чтобы длина оставшейся строки была подходящей (< 1 Кб). Разбиение не должно нарушать функциональных зависимостей между колонками. Поскольку мы предполагаем, что исходная таблица нормализована, в частности все неключевые колонки функционально полно зависят от первичного ключа, то первичный ключ новой таблицы является точной копией первичного ключа исходной таблицы.
Критичным вопросом является вопрос, какие колонки следует переносить в новую таблицу. При разбиении таблицы увеличение производительности будет достигаться только при раздельном доступе к полученным таблицам. При соединении полученных таблиц производительность такого запроса может быть ниже, чем с тем же запросом к исходной таблице из-за дополнительного ввода/вывода. Поэтому проектировщик данных, до того как принять решение о разбиении таблицы, должен проанализировать все транзакции к исходной таблице с высоким приоритетом и при разнесении колонок по таблицам руководствоваться принципом "частота совместного использования колонок в запросах, размещенных в каждой таблице разбиения, должна быть достаточно высока".
Пример. Обратимся к нашей учебной базе данных. Предположим, что в таблице EMPLOYEE необходимо дополнительно сохранять фотографию сотрудника и его автобиографию. Эти два новых поля имею достаточно большой размер, и длина строки таблицы заведомо превысит 1 Кб. Далее предположим, что существует 60 транзакций, которые обращаются к этой таблице. Только четыре из них обращаются ко всем колонкам: при вводе данных о сотруднике при приеме на работу, при внесении изменений, при удалении информации о сотруднике при его увольнении, и запрос руководителя, который имеет высокий приоритет. Все транзакции, кроме одной указанной выше, имеют средний и низкий приоритеты. Частота транзакции с высоким приоритетом ожидается не превышающей двух раз в неделю. Поэтому разбиение таблицы на две не сильно повлияет на производительность транзакций с высоким приоритетом в базе данных в целом.
Частота использования полей в транзакциях приведена в таблице 10.2.
| 1. | Номер личной карточки | EMPNO (PK) | 60 |
| 2. | Фамилия | ENAME | 60 |
| 3. | Имя | LNAME | 50 |
| 4. | Страховка | SSECNO | 15 |
| 5. | Номер подраздления | DEPNO (FK) | 50 |
| 6. | Должность | JOB | 20 |
| 7. | Возраст | AGE | 4 |
| 8. | Стаж | HIREDATE | 4 |
| 9. | Доплаты | COMM | 50 |
| 10. | Зарплата | SAL | 50 |
| 11. | Штрафы | FINE | 50 |
| 12. | Автобиография | Biog | 4 |
| 13. | Фотография | Foto | 4 |
Таким образом, проектировщик базы данных имеет основание для принятия решения о разбиении таблицы EMPLOYEE на две. Скажем, EMPLOYEE и EMP_ADD. Полученный фрагмент скрипта приведен ниже.
CREATE TABLE EMPLOYEE ( EMPNO integer NOT NULL, ENAME char(25), LNAME char(10), DEPNO int, SSECNO char(10), JOB char(25), SAL dec(9,2), COMM dec(9,2), FINE dec(9,2), PRIMARY KEY (EMPNO) );
CREATE TABLE EMP_ADD ( EMPNO integer NOT NULL, AGE date, HIREDATE date NOT NULL WITH DEFAULT, BIOG varchar(254), FOTO long varchar, PRIMARY KEY (EMPNO) );
Внутритабличная денормализация
Внутритабличная денормализация выполняется в пределах одной таблицы, т.е. это процесс введения избыточных колонок в одной таблице с целью увеличения производительности запроса строки по производному значению. Например, если строка содержит две числовых колонки, X и Y, то значение Z, равное произведению X и Y (Z = X*Y), легко вычислить во время выполнения. Однако предположим, что есть запросы, в которых необходимо осуществить поиск по Z (например, Z принадлежит диапазону от 10 до 20). Сохранив избыточные значения Z в столбце, можно построить индекс по Z, и запросы будут использовать этот индекс. Если индекс по Z строить не надо, то решение о его хранении в отдельном столбце зависит от того, что является более приемлемым - увеличение времени загрузки, вызванное необ ходимостью постоянно пересчитывать Z, или увеличение времени сканирования, обусловленное удлинением строк таблицы за счет хранения дополнительной колонки.Приведем еще один часто встречающийся пример внутритабличной нормализации. Допустим, что одинаковый текст хранится в двух видах: с символами в верхнем и в нижнем регистре - для отображения и ввода данных с символами в верхнем регистре. Это бывает необходимо для обеспечения работы ускоренных запросов без учета регистра.
Примечание. Обеспечить приемлемую производительность для таблиц умеренного размера (до 10000 строк) в последнем случае можно и без внутритабличной деномализации, переработав запрос с использованием встроенной функции UPPER.
Восходящая денормализация
Восходящая денормализация предлагает перенос атрибута из подчиненной (дочерней) сущности в родительскую сущность, обычно в форме итоговых данных. На рисунках 10.3 и 10.4 показано, как это можно сделать для сущностей Order и Order Item (Позиция заказа).
Рис. 10.3. Сущности Customer и Order до денормализации
Рис. 10.4. Сущности Customer и Order после денормализации
Например, если в вычисление общей суммы заказа в системы обработки заказов (суммирование колонок Item_Price в таблице Order Item) приводит к снижению производительности, то мы можем повысить производительность этой операции, поместив сумму заказа в избыточном столбце таблицы ORDER. В нашем примере в избыточном столбце хранится сумма значений, но эти приемы применимы к максимальным, минимальным и средним значениям, а также к другим агрегатным показателям.
Таким образом, восходящая денормализация - это процесс введения избыточных колонок в родительских таблицах с целью устранения операций соединения с операциями агрегирования.
Чтобы представить последствия введения денормализации, рассмотрим процедуру сопровождения денормализованных таблиц Order и Order Item, которые сводятся к поддержке следующих бизнес-правил:
Поддержка перечисленных выше бизнес-правил создает дополнительную нагрузку на процессы, выполняющие DML-операции в таблице Order Item. Это и есть цена, которую мы вынуждены заплатить за повышение производительности запросов.
Основы проектирования реляционных баз данных
Хэш-секционирование
Хэш-секционирование (hash partitioning) означает равномерное распределение строк таблицы по назначенным табличным пространствам в зависимости от значения ключа секционирования, который в данном случае хэшируется. Этот вид секционирования удобно применять для строк, у которых распределение значений ключа секционирования неравномерно или плохо группируется. Если проектировщик базы данных принимает решение о создании хэш-секционированной таблицы, то он должен достаточно точно представлять размер этой таблицы, поскольку встроенные в СУБД Oracle алгоритмы хэширования используют этот размер для вычисления позиции строки на физической странице базы данных. Неверное определение размера таблицы может привести к большому числу коллизий, т.е. к попаданию строк с различными значениями ключа на одну и ту же страницу, что приводит к поддержке цепочек переполнения и дополнительному вводу/выводу.Пример. Рассмотрим ту же таблицу Sales, что и в предыдущем примере, и ту же схему (рис. 11.2) табличных пространств. Однако используем в качестве ключа секционирования идентификацию клиента. Отметим, что распределение значений этой колонки может быть очень неравномерно. Фрагмент кода SQL для создания хэш-секционированной таблицы Sales можно написать так:
CREATE TABLE Sales ( s_customer_id number(6), s_amt number(9,2), s_date date) PARTITION BY HASH (s_customer_id) (PARTITION q01 TABLESPACE ts_01, PARTITION q02 TABLESPACE ts_02, PARTITION q03 TABLESPACE ts_03, PARTITION q04 TABLESPACE ts_04 );
Предложение PARTITION BY HASH (s_customer_id) указывает СУБД Oracle выполнить секционирование таблицы по ключу секционирования - s_customer_id. Предложения вида (PARTITION q01 TABLESPACE ts_01 определяют имя секции st_q01 и ее размещение в соответствующем табличном пространстве ts_01.
Индекс со структурой B-Tree
Индекс на основе сбалансированной иерархической структуры, или индекс B-Tree (Balanced Tree structured object), используется как индекс по умолчанию в СУБД Oracle. Эта структура напоминает дерево (если смотреть снизу вверх), в котором сначала считывается самый верхний блок - корневой узел (root), затем блок на следующем уровне - блок-ветвь (branch) и так до тех пор, пока не будет извлечен блок-лист (leaf) с идентификатором строки. Значения ключа сохраняются в индексе (рис. 11.1). Такая структура позволяет сократить до минимума число операций ввода/вывода. Для получения идентификатора строки обычно требуется одно посещение блок-листа, т.е. физической страницы базы данных, отведенной под индекс.
Рис. 11.1. Концептуальная организация B-Tree индекса
Замечание. Следует отметить два случая, когда после выборки идентификатора строки из индекса может понадобиться несколько посещений физической страницы индекса: 1) когда строка имеет длину более одной физической страницы, так называемая расщепленная строка; 2) когда строка за время своего существования в базе данных увеличилась и была перемещена из исходной страницы в другую, так называемая мигрировавшая строка.
Индекс B-Tree характеризуется количеством уровней в индексе (height). Чем меньше уровней, тем выше производительность.
Индекс B-Tree - это физический объект реляционной базы данных, организованный по принципу сбалансированной иерархической структуры и обладающий набором свойств. Сформулируем некоторые свойства индексов со структурой B-Tree.
Узлы-листья содержат полное значение ключа.
Индексы создаются командой SQL CREATE INDEX. В предыдущих лекциях мы уже создавали индексы на основе B-Tree. При создании индекса опционально можно задать ряд параметров. Для получения полного списка параметров следует обратиться к документации по СУБД. Применение некоторых параметров будет показано в следующих разделах.
Пример. В нашей учебной базе создадим для таблицы EMPLOYEE составной индекс по колонкам Ename и Job. При этом проектировщик базы данных не уверен, что этот индекс будет использоваться эффективно, поэтому он задал опцию для сбора статистики для этого индекса.
CREATE INDEX emp_ndx2 ON EMPLOYEE (Ename, Job) COMPUTE STATISTICS;
В этом подразделе мы рассмотрели наиболее часто используемый тип индексов. В последующих подразделах и разделах мы рассмотрим другие типы индексов реляционных баз данных.
Индексирование
Индексирование (indexing) - это способ обеспечения быстрого доступа к значениям колонки или комбинации колонок. Физически новые строки добавляются в конец таблицы, результатом чего становится неупорядоченное размещение значений в колонках. Без использования каких-либо методов упорядочения данных единственным способом просмотра значения колонки со стороны СУБД является последовательный просмотр каждой строки от начала таблицы к ее концу, так называемое сканирование таблицы. Производительность такого сканирования пропорционально размеру таблицы, размеру физической страницы базы данных и длине строки. Одним из способов внесения отношения порядка в значения колонок без нарушения физического расположения строк таблицы является создание объекта реляционной СУБД - индекса (index). Индекс - это объект в реляционной базе данных, который предназначен для организации быстрого доступа к строкам таблицы по значениям одной или более колонок этих строк.О создании индекса мы уже говорили при обсуждении ограничений первичного ключа и внешнего ключа. Тогда индексы предназначались для поддержки целостности первичного ключа и поддержки ограничения ссылочной целостности. В этом разделе пойдет речь об использовании индекса как инструмента повышения производительности обработки запросов.
Концептуально действие индекса состоит в следующем. В индексе содержится упорядоченный список значений колонки или комбинации колонок, а также сведения о местонахождении на жестком диске соответствующих этим значениям строк таблицы. Значения колонки в индексе упорядочены. Несмотря на то, что порядок строк в таблице случаен, индекс можно быстро просмотреть, чтобы найти конкретное значение. Упорядоченный индекс можно просмотреть во много раз быстрее, чем неупорядоченную таблицу. Чем выше степень различия значений ключа в колонке, тем быстрее будет выполняться доступ к строкам этой таблицы.
Так при вставке новой записи в таблицу проверка уникальности первичного ключа реализуется не реальным просмотром индекса, а тем, что требование уникальности предъявляется к значениям колонки первичного ключа в индексе.
Таким образом, индекс - это объект базы данных, который может существенно сократить время поиска нужных строк в таблице.
Замечание. После того как вы создали индекс, оптимизатор СУБД, о котором пойдет речь в последней лекции, будет использовать его всякий раз, когда это ускоряет считывание данных. Обратите внимание на то, что созданный вами индекс может ни разу не использоваться!
Индексы, несомненно, занимают место в базе данных. При вводе новых данных или удалении данных СУБД приходится обновлять и таблицы, и индексы. Это может замедлить выполнение операций модификации данных, особенно для таблиц с большим числом строк. Таким образом, может возникнуть проблема, суть которой состоит в возникновении конфликта между скоростью обновления данных в таблице и скоростью ее считываний. При разрешении этой проблемы следует придерживаться следующего эмпирического правила: создавайте индексы для колонок первичных ключей и других колонок, часто используемых в тех запросах, в которых для выборки данных применяются логические критерии. Если в результате скорость обновления данных ухудшается, то можно рассмотреть вопрос об удалении некоторых индексов.
Каждая таблица базы данных может иметь один или несколько индексов. Индексы могут создаваться по одной колонке или нескольким колонкам таблицы. Колонки, входящие в индекс, принято называть ключевыми полями (key fields) или ключами. Индексы могут быть уникальными и неуникальными. Неуникальный индекс может иметь несколько ключей с одинаковыми значениями.
В СУБД Oracle и SQLBase каждая строка таблицы обладает уникальным идентификатором ROWID - идентификатором строки, который представляет собой псевдоколонку с информацией о точном расположении строки в базе данных и содержит еще некоторую идентифицирующую информацию (идентификатор объекта базы данных, файла данных, блока и строки). Идентификатор строки хранится в индексе вместе со значениями ключевых полей.
Зачем создавать индекс для колонки или группы колонок? Это важный вопрос, и мы на него можем ответить следующим образом:
На этапе физического проектирования реляционной базы данных проектировщику необходимо принять ряд важных решений о том, что и как индексировать. В данном случае важно четко сформулировать правила индексирования. Для чего нужны правила индексирования? Для каждого ИТ-проекта с базами данных проектировщику необходимо создать и оформить в письменном виде правила индексирования, как часть общих правил обеспечения производительности. Поддержка и сопровождение индексов в процессе эксплуатации базы данных является в основном задачей администратора базы данных. Решая задачи обеспечения производительности базы данных, администратор базы данных будет ставить вопрос о перепроектировании физической структуры базы данных (обратные задачи проектирования), в том числе и вопрос об удалении и создании новых индексов. Он может решать эти задачи самостоятельно. Тем более важно знать, по каким правилам и из каких соображений создавались индексы того или иного типа. Разработка таких правил значительно повысит качество эксплу атации базы данных с точки зрения обеспечения ее производительности.
Чтобы решать эти задачи, проектировщик базы данных должен знать, как работает индекс, какие типы индексов поддерживает СУБД, а также понимать смысл методов индексирования.
Сначала мы опишем типы индексов вместе с методами индексирования для каждого типа, затем разберем вопрос о том, как работает индекс, и в заключение дадим некоторые рекомендации по созданию и использованию индексов.
Исключительно индексные таблицы
Индексы могут создаваться на основе значений одной или нескольких колонок. Если требования к данным в запросе удовлетворяются на основе информации из связанного с этими данными индекса, то доступ к базовой таблице не осуществляется. Это обстоятельство привело к идее создания исключительно индексной таблицы (index-organized table). Исключительно индексная таблица является индексом типа B-Tree базы данных, который одновременно исполняет роль таблицы. Все данные такой таблицы хранятся в индексе. Преимуществом создания полностью индексированных таблиц состоит в экономии места хранения на диске и сокращения объема ввода/вывода, поскольку ключевые колонки нет необходимости сохранять еще раз в таблице. Результат выполнения запроса будет получен на основе данных, сохраненных в индексной таблице. Исключительно индексная таблица создается с помощью команды SQL CREATE TABLE, как показано в примере ниже.Пример. Предположим, что в нашей учебной базе требуется в отдельной таблице сохранять и отслеживать проблемы, возникающие по выполнении всех проектов, и частоту возникновения проблемы. Создадим исключительно индексную таблицу для этой таблицы, как показано ниже:
CREATE TABLE Proj_Index ( projno char(8) NOT NULL, t_person char(32) NOT NULL, t_frequency integer, t_problem varchar2(512), CONSTRAINT pk_ndx PRIMARY KEY( projno, t_person) ) ORGANIZATION INDEX TABLESPACE ts_ndx1 PCTTHRESHOLD 20 INCLUDING t_frequency OVERFLOW TABLESPACE ts__of_ndx1;
Команда CREATE TABLE не отличается ничем от других команд создания таблиц до тех пор, пока не встретится предложение ORGANIZATION INDEX, которое указывает СУБД на создание исключительно индексной таблицы. Для размещения индекса на диске указывается табличное пространство. Параметр PCTTHRESHOLD указывает, что оставшуюся часть строки нужно сохранять в заданном табличном пространстве - сегменте переполнения, если данная строка превышает размер физической страницы базы данных на указанное число процентов. Параметр INCLUDING определяет имя колонки, с которой строка индексной таблицы делится на две части: индексную и переполнения. Эта колонка может быть частью первичного ключа таблицы или неключевой колонкой. Все неключевые колонки, которые следуют за указанной колонкой, размещаются в сегменте переполнения, который определяется ключевым словом OVERFLOW.
О некоторых параметрах проектирования индексов
Когда проектировщик базы данных приступает к проектированию индексов, то он должен иметь некоторый способ оценки качества создаваемого индекса. Введем несколько понятий, с помощью которых проектировщик может грубо оценить качество потенциального индекса.Кардинальностью колонки (cardinality) таблицы называется число дискретных различных значений колонки, которые встречаются в строках таблицы. Например, если в таблице EMPLOYEE мы заводим колонку для указания пола - SEX, то кардинальность этой колонки есть 2, так как в природе у людей существует только два пола - мужской и женский. Для колонки первичного ключа кардинальность будет равна числу строк в таблице.
Причиной, по которой кардинальность колонки важна для проектирования индексов, состоит в том, что кардинальность индексируемой колонки определяет число уникальных входов, которые должны сохраняться в индексе, т.е. число записей в индексе. Так, для индексируемой колонки SEX будет существовать два уникальных входа, которые будут повторяться много раз в индексе. При предположении равновероятного распределения пола сотрудников на 100000 строк в таблице EMPLOYEE каждый вход индекса будет повторяться 50000 раз. СУБД вряд ли будут принимать решение об использовании такого индекса при построении плана запроса.
Определить кардинальность потенциальной колонки индексирования в существующей базе данных достаточно просто:
SELECT COUNT (DISTINCT колонка) FROM таблица
При проектировании новой базы данных проектировщик должен оценить кардинальность всех потенциальных индексируемых колонок во всех таблицах базы данных, исходя из имеющейся документации.
Способ, с помощью которого СУБД оценивает действие кардинальности, состоит в использовании фактора селективности выборки (selectivity factor). Фактора селективности выборки индекса определяется как величина, обратная кардинальности индексной колонки:
Фактор селективности оценивает потенциальный объем операций ввода/вывода. Чем меньше фактор селективности, тем меньше требуется операций ввода/вывода для получения результирующего множества строк таблицы.
СУБД оценивает эту величину, чтобы решить, использовать индекс для доступа к строкам таблицы или нет. Какие формулы используются для оценки фактора селективности в СУБД, мы рассмотрим в последней лекции этого курса.
В заключение раздела мы приведем список правил для определения колонок, которые являются хорошими и плохими кандидатами для индексирования. Эти правила могут быть использованы проектировщиком базы данных при принятии решения о построении индексов реляционной базы данных.
Хорошими кандидатами для индексирования обычно являются:
Факторы, влияющие на низкую эффективность индексов:
СУБД оценивает эту величину, чтобы решить, использовать индекс для доступа к строкам таблицы или нет. Какие формулы используются для оценки фактора селективности в СУБД, мы рассмотрим в последней лекции этого курса.
В заключение раздела мы приведем список правил для определения колонок, которые являются хорошими и плохими кандидатами для индексирования. Эти правила могут быть использованы проектировщиком базы данных при принятии решения о построении индексов реляционной базы данных.
Хорошими кандидатами для индексирования обычно являются:
Факторы, влияющие на низкую эффективность индексов:
Параметры индексирования
СУБД Oracle предусмотрено еще несколько параметров индексирования, которые позволяют улучшить традиционные для всех СУБД индексы со структурой B-Tree. К таким модификациям, помимо исключительно индексных таблиц, относятся битовые индексы, индексы с обращением ключа, индексы на основе значения функций.Каждый бит так называемого битового (bitmap) индекса относится к идентификатору строки ROWID в табличном объекте. Если некоторая строка содержит данное ключевое значение, то в индексе для этого значения сохраняется единица. Такая организация индекса может в некоторых случаях значительно повысить производительность выборки данных, т.к. для извлечения строк с определенным значением индекса СУБД нужно лишь найти все единицы, отвечающие ключу. Физически такой индекс организован на основе структуры B-Tree, но задача сводится к поиску данной строки за счет одной операции чтения битовой индексной структуры. Этот тип индекса очень эффективен для индексирования колонок с небольшим кардинальным числом - пол, цвет и т.д. Если значений у колонки буде много, то объем ввода/вывода будет возрастать.
Пример. Для нашей учебной базы данных можно построить битовый индекс для таблицы EMPLOYEE по колонке DEPNO, как показано ниже:
CREATE BITMAP INDEX emp_ndx ON EMPLOYEE (DEPNO);
В индексе с обращением ключа (reverse-key index) применяется обращение байтов индексируемой колонки числового типа. Этот прием позволяет получать равномерное распределение значений колонок среди блок-листов индекса со структурой B-Tree. Этот индекс хорошо подходит для индексирования колонок с последовательной нумерацией или нумерацией с заданным шагом. Заметим, что такие индексы применяются только для возвращения отдельных строк, и с их помощью нельзя выполнить поиск значений в некотором диапазоне. Вы не можете применить опцию REVERSE к битовым индексам и исключительно индексным таблицам.
Пример. В нашей учебной базе данных числовые ключи, содержащие последовательные числа, есть, в частности, в таблице PLOYEE - EMPNO.
Мы можем определить для этой таблиц дополнительный индекс с обращением ключа для извлечения записи о сотруднике. Заметим, что для этой колонки уже есть индекс первичного ключа.
CREATE INDEX dep_ndx ON EMPLOYEE (EMPNO) REVERSE;
В процессе эксплуатации администратор базы данных может перестроить этот индекс с помощью команды ALTER INDEX, как показано ниже
ALTER INDEX EMPLOYEE REBUILD NOREVERSE;
Если в предложении WHERE используется функция по индексированной колонке, то обычно СУБД не применяют этот индекс при организации доступа к строкам таблицы. Но при создании индекса на основе значения функции (function-based index), которая является той же функцией, что и в предложении WHERE, то СУБД использует такой индекс для считывания строк, удовлетворяющих критерию отбора. Индексы на основе значений функции могут быть битовыми индексами.
Пример. Обратимся к нашей учебной базе. Предположим, что при поиске сотрудников по фамилии таковая вводится на верхнем регистре, как в примере ниже:
SELECT * FROM EMPLOYEE WHERE UPPER(:ENAME) ORDER BY UPPER(:ENAME);
Тогда, даже при наличии индекса по колонке ENAME, СУБД будет сканировать таблицу, не обращаясь к этому индексу. Проектировщик базы данных, учитывая, что частота таких транзакций будет очень высокой, может предусмотреть создание индекса на основе значений функции от колонки EMANE, как показано ниже:
CREATE INDEX emp_ndx_e ON EMPLOYEE UPPER(:ENAME);
При наличии в базе данных такого индекса СУБД Oracle будет его использовать при обработке вышеприведенного запроса.
Повышение производительности запросов: Кластеры
Самой медленной операцией, выполняемой СУБД, является операция чтения данных с диска или запись данных на диск. Если существует возможность уменьшить в несколько раз число таких операций, то общая производительность базы данных может заметно увеличиться.Следует помнить, что СУБД считывает с диска или записывает на диск за один раз одну физическую страницу данных, размер которой колеблется в зависимости от аппаратной платформы от 512 байт до 4 Кб. Таким образом, если можно физически хранить данные, к которым часто происходит совместное обращение, на одной и той же странице диска или на страницах, физически близко расположенных друг к другу, то скорость доступа к этим данным повышается.
Кластеризация (Clustering) - это способ физического размещения рядом, на одной физической странице данных, строк, доступ к которым осуществляется при помощи одинакового значения колонки (ключа) с целью увеличения производительности. Такой ключ называется кластерным ключом. Значением кластерного ключа являются значения одинаковых по смыслу колонок строк кластеризуемых таблиц. Ключ может быть либо хэш-ключом, либо индексным ключом. Если ключ является хэш-ключом, то физическое размещение определяется функцией преобразования ключа (хэширования) и мы имеем дело с уже известной нам из предыдущих разделов таблицей хэширования или хэш-кластером. Если это индексный ключ, то для идентификации страницы данных в кластере используется индекс со структурой B-Tree, в котором сроки, имеющие одинаковые значения ключа, размещаются либо в одной странице, либо в смежных стран ицах индекса. Такой кластер называется индексным кластером. Строки, которые хранятся в индексном кластере, не обязательно должны принадлежать одной таблице. Таким образом, кластеры являются одним из методов хранения таблиц данных, поддерживаемых СУБД. Кластер - это группа таблиц, которая разделяет общие физические страницы данных при совместном использовании в запросах общих колонок этих таблиц.
На практике индексный кластер создается для совместного хранения строк, связанных ограничением внешнего и первичного ключей.
Совместное хранение строк родительской и дочерней таблиц может значительно ускорить выполнение соединения этих таблиц.
Пример. Рассмотрим таблицы DEPARTAMENT и EMPLOYEE нашей учебной базы данных. Они некластеризованы и хранятся каждая на своих физических страницах. Предположим, что анализ запросов показывает, что в 80% запросов эти таблицы используются совместно, при этом соединение выполняется по колонке DEPNO. Проектировщик базы данных может решить построить кластер для этих двух таблиц. На рисунке ниже показана концептуальная сторона такого решения.
До кластеризации строки из таблиц сохраняются отдельно в своих физических областях на диске.
| DEPARTMENT | |||
| DEPNO | DNAME | LOC | … |
| 10 | Торговля | Москва | |
| 20 | Консалтинг | Черноголовка | |
| EMPLOYEE | |||
| EMPNO | ENAME | LNAME | DEPNO |
| 996 | Козырев | Сергей | 10 |
| 997 | Сапегин | Алексей | 20 |
| CLUSTER | ||||
| DEPNO | ||||
| 10 | DNAME | LOC | … | |
| Торговля | Москва | … | ||
| … | … | … | ||
| EMPNO | ENAME | LNAME | … | |
| 996 | Козырев | Сергей | … | |
| … | … | … | ||
| 20 | DNAME | LOC | … | |
| Консалтинг | Черноголовка | … | ||
| EMPNO | ENAME | LNAME | … | |
| 997 | Сапегин | Алексей | … | |
| … | … | … | … | |
Кластеризация может существенно ускорить работу с соединениями. Однако, планируя использование кластеров, проектировщик базы данных должен учитывать следующие факторы:
В силу вышеперечисленных обстоятельств кластеры не рекомендуется создавать для таблиц с интенсивным обновлением данных. Для того чтобы таблица была хорошим кандидатом для ее кластеризации, должны выполняться по крайней мере следующие условия:
В силу вышеперечисленных обстоятельств кластеры не рекомендуется создавать для таблиц с интенсивным обновлением данных. Для того чтобы таблица была хорошим кандидатом для ее кластеризации, должны выполняться по крайней мере следующие условия:
Из этого следует, что существуют две основные причины использования кластеров: это необходимость а) обеспечить прямой доступ к строке за одну операцию чтения; и б) сократить число операций ввода/вывода при доступе к часто совместно используемым данным путем размещения их в близко расположенных физических страницах базы данных.
С физической точки зрения кластер находится отдельно от таблиц. Он создается с указанием параметров хранения, а затем в нем последовательно создаются кластеризованные таблицы. При описании кластера нужно указать колонки или колонку, для которых СУБД сформирует кластер, и таблицы, которые будут включены в его состав. При обработке данных СУБД будет размещать строки, содержащие одинаковые значения в колонках кластера, физически максимально близко. В результате строки таблицы могут быть распределены среди нескольких дисковых страниц, но первичные и внешние ключи обычно располагаются на одной странице.
Пример. Вернемся к нашей учебной базе данных и напишем фрагмент скрипта для создания кластера для таблиц DEPARTAMENT и EMPLOYEE. Для создания кластеров используется команда SQL CREATE CLUSTER, которая в нашем случае будет иметь вид
Хэш- кластер является альтернативной техникой создания таблиц данных по отношению к индексному кластеру или некластеризованной таблице.
Пример. Рассмотрим нашу учебную базу данных с целью создания хэш-кластера для таблицы EMPLOYEE. На рис. 11.3 ниже показано, как будет выполняться доступ к записям таблицы до и после кластеризации.
Рис. 11.3. Доступк строке таблицы EMPLOYEE через индекс по колонке EPMNO
SELECT * FROM EMPLOYEE WHERE EMPNO= 997;
До кластеризации по колонке EPMNO доступ будет выполняться через индекс, и согласно рисунку 11.3 потребуется 4 операции ввода/вывода, чтобы получить результирующую строку.
После кластеризации по колонке EPMNO строки таблицы EMPLOYEE будут сохраняться в структуре, которая условно приведена на рисунке ниже. После хэширования ключа потребуется одна операция ввода/вывода, чтобы получить результирующую строку, если нет цепочек переполнения.
| CLUSTER | ||||
| Хэш-ключ | Кластерный ключ | |||
| 110 | EMPNO | ENAME | LNAME | … |
| 996 | Козырев | Сергей | … | |
| … | … | … | ||
| 120 | EMPNO | ENAME | LNAME | … |
| 997 | Сапегин | Алексей | … | |
Пример. Создадим хэш-кластер для таблицы EMPLOYEE нашей учебной базы данных. Фрагмент скрипта приведен ниже.
CREATE CLUSTER PERSONNEL (EMPNO integer) SIZE 512 HASHKEYS 500 -- STORAGE (INITIAL 100K NEXT 50K PCTINCREASE 10) ;
Число уникальных значений хэш-ключа задается параметром HASHKEYS, после достижения этого значения в таблицы будут возникать коллизии - ситуации, когда разные хэшированные ключи должны будут размещаться в одном блоке. Это приводит к созданию при вставке строк так называемых цепочек переполнения, из-за которых увеличивается число доступов при выборке результирующей строки.
Параметр SIZE определяет максимальное число хэш-ключей, размещаемое на физической странице базы данных. Он равен оценке общего пространства в байтах, требуемого для сохранения среднего числа строк, связанного с каждым значением хэш-ключа. Если доступного пространства на странице - 1600 байт, а значение параметра - 512 байт, то три значения хэш-ключа будут распределяться на физической странице.
С помощью предложения HASH IS вы можете переопределить хэш-функцию, которую СУБД Oracle использует по умолчанию.
Пример. Если у нас есть хэш-кластер для таблицы EMPLOYEE и кластерный ключ определен как код домашнего адреса сотрудника, то вероятно, что будет случаться много коллизий в хэш-кластере, если городок, где живут сотрудники, невелик. Для того чтобы избежать такой коллизии, можно переопределить встроенную хэш-функцию Oracle в команде CREATE CLUSTER, добавив предложение HASH IS, как показано ниже.
CREATE CLUSTER personnel (home_area_code number, home_prefix number ) HASHKEYS 20 HASH IS MOD(home_area_code + home_suffix_tel, 101);
В примере добавлено некоторое число к коду домашнего адреса, чтобы изменить распределение значений хэш-ключа с целью избежать коллизий. В качестве такого числа взяты две последние цифры домашнего телефона.
В заключение отметим следующее. Несмотря на то, что СУБД Oracle, так же как и СУБД SQLBase, интенсивно использует кластеры для доступа к системным таблицам базы данных, автор настоящего курса рекомендует проектировщикам базы данных проявлять осторожность при принятии решения о кластеризации таблиц при создании новой базы данных. Выигрыш в производительности может быть не слишком высок по сравнению с другими проектными решениями. Проектирование кластеров - штучная работа. Очень полезно знать статистику использования аналогичного кластера при эксплуатации аналогичной базы данных, чтобы построить высокопроизводительный кластер. Придерживайтесь следующих эмпирических правил:
Литература: [7], [14], [20], [23], [45].
Секционирование индексов
В СУБД Oracle предусмотрено секционирование индексов (index partitioning), которое означает преднамеренное распределение индексов таблиц по назначенным табличным пространствам в соответствии с ключом секционирования. Секционирование индексов может быть глобальным и локальным. Локально секционированный индекс имеет такой же ключ секционирования, количество табличных пространств и правила секционирования, что и отвечающая ему базовая таблица. Глобально секционированный индекс содержит предложение PARTITION BY RANGE, в котором задаются параметры секционирования, отличные от параметров секционирования соответствующей базовой таблицы. Секционированные индексы могут быть префиксными или непрефиксными. В случае префиксного секционированного индекса секционирование производится по ключу секционирования, который содержит основную часть индексного ключа. В случае непрефиксных секционированных индексов ключа секционирования секционирование вып олняется по значениям, отличным от значений колонки индексирования.Индексы могут быть секционированы и в случае, когда индексируемая таблица не секционируется. В этом случае по умолчанию предполагается, что индекс является глобальным секционированием индексов. В Oracle не предусмотрена поддержка глобальных непрефиксных секционированных индексов.
В локально секционированном индексе ключевые значения одной секции индекса соответствуют строкам таблицы из одной ее секции.
Пример. Создадим локальный секционированный индекс для таблицы Sales (рис. 11.2). Ключом секционирования этой таблицы является колонка s_date. Фрагмент кода создания индекса приведен ниже.
CREATE INDEX sales_ndx ON Sales (s_date) LOCAL (PARTITION st_i_q01 TABLESPACE ts_01, PARTITION st_i_q02 TABLESPACE ts_02, PARTITION st_i_q03 TABLESPACE ts_03, PARTITION st_i_q04 TABLESPACE ts_04 );
Локально секционированный индекс называется равносекционированным (equi-partitioned), если он имеет то же число секций и те же правила секционирования, что и его базовая таблица. Обратите внимание, что в примере при создании индекса не использовалось предложение PARTITION BY RANGE.
Oracle автоматически берет структуру секционирования для индекса из структуры секционирования базовой таблицы Sales. Также можно опустить и предложения типа PARTITION st_i_q02 TABLESPACE ts_02. Если опущено PARTITION, то Oracle автоматически создаст имена секций. Если пущено TABLESPACE, то Oracle автоматически разместит секции в тех же табличных пространствах, в которых находятся соответствующие секции базовой таблицы.
Глобально секционированный индекс имеет структуру секций, отличную от структуры секций базовой таблицы данного индекса. В качестве примера создадим глобально секционированный индекс для таблицы Sales из наших предыдущих примеров.
Пример. В качестве ключа секционирования для индекса используем колонку s_customer_id. Во фрагменте кода ниже для секций индекса используются другие индексные пространства ts_i_01, ts_i_02, ts_i_03. Число секций индекса не совпадает с числом секций базовой таблицы для этого индекса:
CREATE INDEX sales_ndx ON Sales (s_customer_id) GLOBAL PARTITION BY RANGE (s_customer_id) (PARTITION st_i_q1 VALUES LESS THAN (10000) TABLESPACE ts_i_01, PARTITION st_i_q2 VALUES LESS THAN (20000) TABLESPACE ts_i_02, PARTITION st_i_q3 VALUES LESS THAN (MAXVALUE) TABLESPACE ts_i_03, );
Локально секционированный индекс может быть создан по колонке, отличной от ключа секционирования базовой таблицы индекса. В примере ниже создается такой непрефиксный индекс для таблицы Sales.
Пример. В качестве колонки секционирования для индекса выбрана колонка s_customer_id, а для секций индекса выбраны другие табличные пространства ts_i_01, ts_i_02, ts_i_03, ts_i_04, чем для секций базовой таблицы индекса.
CREATE INDEX sales_ndx_1 ON Sales (s_customer_id) LOCAL (PARTITION st_i_q01 TABLESPACE ts_i_01, PARTITION st_i_q02 TABLESPACE ts_i_02, PARTITION st_i_q03 TABLESPACE ts_i_03, PARTITION st_i_q04 TABLESPACE ts_i_04 );
При принятии решения о секционировании индексов проектировщик базы данных должен иметь в виду следующее:
Секционирование по диапазону
Секционирование по диапазону (range partitioning) означает распределение строк таблицы на различные предопределенные табличные пространства в зависимости от значения ключа секционирования. Доступ к такой таблице, как и к любой другой, осуществляется по ее имени, причем доступ к секциям, расположенным в каждом табличном пространстве, можно получить отдельно. Например, таблицу, содержащую финансовые квартальные отчеты организации, можно секционировать по дате таким образом, что отчеты по каждому кварталу будут храниться в отдельном табличном пространстве. При такой организации секций данные только по одному кварталу будут выбираться из одного табличного пространства, что повысит эффективность работы базы данных в целом.Секционирование по диапазону базируется на упорядочении строк таблицы в секциях (табличных пространствах) на основе значения колонок ключа секционирования. Концептуально таблица, секционированная по диапазону, устроена как на рис. 11.2 в примере ниже. Для создания секционированных таблиц используется команда SQL CREATE TABLE с предложением PARTITION. В СУБД Oracle ключ секционирования не может иметь тип LONG.
Рис. 11.2. Пример секционирования подиапазону
Пример. Рассмотрим систему обработки заказов. Предположим, что в ней есть таблица Sales, в которой сохраняются данных о количестве, времени и цене продаж для каждого клиента. Проектировщик базы данных может использовать секционирование по диапазону, а именно - по кварталу, для представления этой таблицы в базе данных. Предположим, что мы имеем четыре определенные ранее табличных пространства c именами ts_01, ts_02, ts_03, ts_04, распределенные по четырем дискам, как показано на рисунке ниже.
Фрагмент скрипта ниже определяет таблицу Sales с физическим размещением секций, как на рисунке выше:
CREATE TABLE Sales ( s_customer_id number(6), s_amt number(9,2), s_date date) PARTITION BY RANGE (s_date) (PARTITION st_q01 VALUES LESS THAN ('01-apr-2002') TABLESPACE ts_01, PARTITION st_q02 VALUES LESS THAN ('01-jul-2002') TABLESPACE ts_02, PARTITION st_q03 VALUES LESS THAN ('01-oct-2002') TABLESPACE ts_03, PARTITION st_q04 VALUES LESS THAN (MAXVALUE) TABLESPACE ts_04 );
Предложение PARTITION BY RANGE (s_date) указывает СУБД Oracle выполнить секционирование таблицы по ключу секционирования - s_date. Предложения вида (PARTITION st_q01 VALUES LESS THAN ('01-apr-2002') TABLESPACE ts_01 определяют имя секции st_q01 и ее размещение в соответствующем табличном пространстве ts_01.
Чтобы получить доступ к строкам таблицы, расположенным в определенной секции, узнать о продажах в третьем квартале, можно использовать команду SELECT, как показано ниже:
SELECT s_customer_id, s_amt FROM Sales PARTITION (st_q03);
Как мы можем увидеть, для этого нужно указать опцию PARTITION (имя секции) после имени таблицы в предложении FROM.
Администратор базы данных может легко удалять, добавлять, перемещать, расщеплять, усекать и изменять секции с помощью команды ALTER TABLE. Удалить отдельную секцию можно также, удалив соответствующее ей табличное пространство.
Секционирование представлений
В Oracle есть возможность секционировать представления. Основная идея секционирования представлений проста. Пусть физическая таблица разбита на несколько таблиц (необязательно с помощью методов секционирования таблиц) в соответствии с критерием разбиения, который делает обработку запроса более производительной. Критерий разбиения будем называть предикатом секционирования. Тогда мы можем создать и настроить представления таким образом, чтобы с их помощью обращение к данным этих таблиц было проще для пользователя. Секция представления определяется в соответствии с диапазоном значений ключа секционирования. Запросы, которые используют диапазон значений для выборки данных из секций представления, будут получать доступ только к тем секциям, которые соответствуют диапазонам значений ключа секционирования.Секции представления могут быть определены предикатами секционирования, заданными либо при помощи ограничения CHECK, либо с использованием предложения WHERE. Покажем, как могут быть применены оба приема на примере несколько модифицированной таблицы Sales, которую мы рассматривали в предыдущем разделе. Допустим, что данные о продажах для календарного года размещаются в четырех отдельных таблицах, каждая из которых соответствует кварталу года - Q1_Sales, Q2_Sales, Q3_Sales и Q4_Sales.
Пример. Секционирование представлений с помощью ограничения CHECK. С помощью команды ALTER TABLE мы можем добавить ограничения на колонку s_date каждой таблицы, чтобы ее строки соответствовали одному из кварталов года. Созданное затем представление sales дает возможность обращаться к этим таблицам - как к одной, так и по отдельности:
ALTER TABLE Q1_Sales ADD CONSTRAINT C0 CHECK (s_date BETWEEN 'jan-1-2002' AND 'mar-31-2002'); ALTER TABLE Q2_Sales ADD CONSTRAINT C1 CHECK (s_date BETWEEN 'apr 1-2002' AND 'jun-30-2002'); ALTER TABLE Q3_Sales ADD CONSTRAINT C2 check (s_date BETWEEN 'jul-1-2002' AND 'sep-30-2002'); ALTER TABLE Q4_Sales ADD CONSTRAINT C3 check (s_date BETWEEN 'oct-1-2002' AND 'dec-31-2002');
CREATE VIEW sales_v AS SELECT * FROM Q1_Sales UNION ALL SELECT * FROM Q2_Sales UNION ALL SELECT * FROM Q3_Sales UNION ALL SELECT * FROM Q4_Sales;
Преимуществом такого секционирования представлений является то, что предикат ограничения CHECK не оценивается для каждой строки запроса. Такие предикаты исключают вставку в таблицы строк, не соответствующих критерию предиката. Строки, соответствующие предикату секционирования, извлекаются из базы данных быстрее.
Пример. Секционирование представлений с помощью предложения WHERE. Создадим представление для тех же таблиц, что и в примере выше:
CREATE VIEW sales_v AS SELECT * FROM Q1_Sales WHERE s_date BETWEEN 'jan-1-2002' AND 'mar-31-2002' UNION ALL SELECT * FROM Q2_Sales WHERE s_date BETWEEN 'apr-1-2002' AND 'jun-30-2002' UNION ALL SELECT * FROM Q3_Sales WHERE s_date BETWEEN 'jul-1-2002' AND 'sep-30-2002' UNION ALL SELECT * FROM Q4_Sales WHERE s_date BETWEEN 'oct-1-2002' AND 'dec-31-2002';
Второй метод имеет некоторые недостатки. Во-первых, критерий секционирования проверяется во время выполнения для всех строк во всех секциях, которые охватываются запросом. Во-вторых, пользователи могут ошибочно вставить строку не в ту секцию, т.е. вставить запись, относящуюся к первому кварталу, в третий квартал, что приведет к неправильной выборке данных для этих кварталов.
У этого приема есть и достоинство по сравнению с использованием ограничения CHECK. Вы можете разместить секцию, соответствующую предикату WHERE, на удаленной базе данных. Фрагмент определения преставления приведен ниже:
SELECT * FROM east_sales@icp.ac.ru WHERE LOC = 'EAST' UNION ALL SELECT * FROM west_sales@ioc.ac.ru WHERE LOC = 'WEST';
Проектировщик базы данных при принятии решения о создании секционированных представлений должен принимать во внимание следующие факторы:
В этом разделе мы рассмотрели некоторые приемы увеличения производительности обработки транзакций, основанные на секционировании объектов реляционной базы данных - базовых таблиц, индексов базовых таблиц и представлений. Основная задача секционирования: с помощью встроенных команд СУБД разбить таблицы большого объема на ряд физических фрагментов в соответствии с некоторым критерием секционирования, чтобы сократить объем ввода/вывода при обработке фрагментов. Секционирование очень часто используется при работе с таблицами большого объема. Проектировщику базы данных, если он определил наличие в проектируемой базе данных сохраняемых объектов большого объема (более 1 Гб), обязательно следует рассмотреть возможность использования техники секционирования.
Секционирование
Во многих базах данных в таблицах хранится огромное количество данных. Чем больше размер таблицы, тем больше времени потребуется как для некоторых операций по выборке строк таблицы, так и для выполнения некоторых функций администратора базы данных. Например, для резервного копирования и восстановления. Большие по размеру индексированные таблицы имеют также большие индексы, которые требуют много времени СУБД для работы с ними.Секционирование (partitioning) - это способ физического распределения таблиц и индексов среди двух или более табличных пространств в зависимости от значений ключевых колонок таблиц с целью повышения производительности операций ввода/вывода. Фрагмент таблицы, расположенный в отдельном табличном пространстве, будем называть секцией таблицы. Секционирование также повышает эффективность резервного копирования и восстановления за счет выполнения этих задач с участием меньшего объема данных. Обсуждению создания табличных пространств далее будет посвящен отдельный раздел следующей лекции. Для понимания данного материала нам достаточно знать, что это предопределенный поименованный фрагмент памяти на одном или нескольких дисках, к которому можно обращаться в предложениях SQL по имени.
В осуществлении секционирования одним из важных понятий является колонка таблицы, относительно значений которой СУБД будет делать физическое разнесение таблицы по различным табличным пространствам на жестких дисках. Эти колонка называется ключом секционирования (partition key).
В СУБД Oracle поддерживается несколько видов секционирования: секционирование по диапазону, хэш-секционирование, составное секционирование, а также различные виды секционирования индексов.
Составное секционирование
Составное секционирование (composite partitioning) является комбинацией секционирования по диапазону и хэш-секционирования. Это означает, что таблица сначала распределяется среди табличных пространств на основе диапазона значений ключа секционирования, далее каждая из полученных секций диапазонов делится на подчиненные секции или подсекции, и затем строки равномерно распределяются среди подчиненных секций по значению хэш-ключа.Пример. Рассмотрим ту же, что и в предыдущем примере таблицу Sales и ту же схему (рис. 11.2) табличных пространств. В качестве ключа секционирования по диапазону используем дату продажи. В качестве ключа хэш-секционирования -идентификацию клиента. Однако теперь каждая секция по диапазону будет разделена на предопределенное число подсекций. Фрагмент кода SQL для создания таблицы Sales с составным секционированием можно написать так:
CREATE TABLE Sales ( s_customer_id number(6), s_amt number(9,2), s_date date) PARTITION BY RANGE (s_date) SUB PARTITION BY HASH (s_customer_id) SUB PARTITION 4 STORE IN (ts_01, ts_02, ts_03, ts_04) (PARTITION q01 VALUES LESS THAN ('01-apr-2002'), PARTITION q02 VALUES LESS THAN ('01-jul-2002'), PARTITION q03 VALUES LESS THAN ('01-oct-2002'), PARTITION q04 VALUES LESS THAN (MAXVALUE) );
Секции q01, q02, q03, q04 будут содержать строки с диапазоном дат, которые определены в предложениях типа PARTITION q02 VALUES LESS THAN ('01-jul-2002') и будут распределены в табличных пространствах ts_01, ts_02, ts_03, ts_04. Предложение SUB PARTITION 4 предписывает СУБД Oracle разбиение каждой секции на четыре логические единицы, а предложение SUB PARTITION BY HASH (s_customer_id) распределяет строки заданного диапазона среди этих четырех подчиненных секций.
Основы проектирования реляционных баз данных
Константы, переменные и типы в PL/SQL
Переменная или константа определяется своим именем, которое является допустимым именем в СУБД Oracle. Любая константа или переменная должна иметь один из допустимых в СУБД Oracle типов. Константа идентифицируется ключевым словом CONSTANT и отличается от переменной тем, что попытка изменить ее значение в программе приведет к ошибке.Для определения констант и переменных используется следующий синтаксис:
Имя [CONSTANT] тип данных [:= значение]; Пример. Рассмотрим пример простой программы, которая вычисляет значение синуса двух углов, кратных p.
-- переменные окружения set serveroutput on; set echo on; DECLARE Pi CONSTANT real :=3.14; x real :=1; BEGIN DBMS_OUTPUT.PUT_LINE ('y ='|| sin(Pi*x)); x:=x+1; DBMS_OUTPUT.PUT_LINE ('y ='|| sin(Pi*x)); END; /
Установка переменных окружения определяет режим вывода на терминал пользователя. Системная процедура DBMS_OUTPUT.PUT_LINE обеспечивает вывод данных на терминал. Символ / указывает на завершение текста программы и является командой к выполнению программы.
Курсоры PL/SQL
Курсор - это поименованный запрос, содержащий некоторое число строк в выборке. По сути, курсор является некоторой структурой, через которую пользователь получает доступ к строкам результирующей таблицы запроса.Рассмотрим пример доступа к информации, которая хранится в базе данных, с использованием курсоров.
Пусть в базе данных есть таблица базы данных с именем T01, такая, как показана ниже.
| A1 number | 1 | 2 | 3 |
| A2 varchar2(5) | abc | cba | bca |
| A3 char(1) | A | B | C |
Опишем курсор для доступа к данным таблицы Т01.
CURSOR cur01 IS SELECT * FROM T01;
Работа с курсором выполняется по следующему алгоритму:
OPEN cur01;
FETCH cur01 INTO x1,x2,x3;
И т.д.
В PL/SQL для курсоров предусмотрено несколько методов. Метод %NOTFOUND возвращает булевское истинное значение, если выборка в курсор пуста. Метод %FOUND возвращает булевское истинное значение, если выборка в курсор непуста. После открытия курсора до первой команды FETCH значения, возвращаемые этими методами, равны NULL. Метод %ROWCOUNT возвращает число строк в выборке после открытия курсора.
Предопределенный в PL/SQL метод %TYPE позволяет определить тип переменной как совпадающий с типом переменной таблицы.
PL/SQL поддерживает тип данных RECORD, который позволяет создать объект, соответствующий строке таблицы, как показано в примере ниже.
DECLARE TYPE t01_rec_type IS RECORD ( x1 t01.A1%TYPE, x2 t01.A2%TYPE, x3 t01.A3%TYPE); t01_rec t01_rec_type; … FETCH cur1 INTO t01_rec; DBMS_OUTPUT.PUT_LINE (cur1%ROWCOUNT||' '||t01_rec.x2); ѕ.
Обработка исключительных ситуаций в PL/SQL
Исключительная ситуация - это возникновение предопределенного и описанного события в системе. Например, ошибки преобразования типов переменных или переполнения при делении на нуль. Пример некоторых предопределенных ситуаций, распознаваемых в PL/SQL, приведен в таблице 12.1 ниже. Для получения полного списка таких ситуаций следует обратиться к документации по PL/SQL.| NOT_LOGGED_ON | Попытка выполнить действие без подключения к серверу |
| INVALID_CURSOR | Ссылка на недопустимый курсор или недопустимая операция с курсором |
| NO_DATA_FOUND | Не найдены данные, соответствующие команде SELECT INTO |
| DUP_VAL_ON_INDEX | Попытка вставить дубликат значения в колонку с ограничением на уникальное значение |
| VALUE_ERROR | Арифметическая ошибка, ошибка усечения или преобразования |
Операторы управления выполнением программы PL/SQL
Операторы PL/SQL выполняются последовательно. Такая схема называется потоком команд. Изменить последовательный порядок выполнения команд можно с помощью команд управления потоком - оператором ветвления, оператором цикла и командой выхода из цикла.Оператор IF условие TNEN группа операторов 1 ELSE группа операторов 2 позволяет проверить условие и в зависимости от результата проверки выполнить различные группы операторов. Если условие принимает значение TRUE, то выполняется группа операторов 1, в противном случае - группа операторов 2. Границы действия оператора IF определяются закрывающейся операторной скобкой END IF. Для расширения структуры ветвления предусмотрена операторная скобка ELSIF.
Синтаксис оператора ветвления следующий:
IF Условие THEN группа операторов 1 ELSIF условие 1 THEN Группа операторов 3 ELSIF … ELSE группа операторов 2 END IF Пример. Изменение потока команд
DECLARE Pi CONSTANT real :=3.14; x real :=1; BEGIN x:=Input_Data; IF (x>0.5) THEN DBMS_OUTPUT.PUT_LINE ('y ='|| sin(Pi*x)); ELSIF (x< 0.4) THEN DBMS_OUTPUT.PUT_LINE ('y ='|| cos(Pi*x)); ELSE x:=x+1; DBMS_OUTPUT.PUT_LINE ('y ='|| sin(Pi*x)); END IF; END; /
Переменная, имени которой предшествует знак &, вводится с терминала пользователя.
Организация цикла в программах на PL/SQL может быть выполнена несколькими способами. Рассмотрим примеры вычисления суммы.
Пример. Оператор LOOP.
DECLARE X number; I number; Limit number:=1000; BEGIN I:=0; X:=0; LOOP EXIT WHEN I > Limit; I:=I+1; X:=X+I*I; END LOOP; DBMS_OUTPUT.PUT_LINE (x); END; /
Оператор LOOP открывает цикл. Конструкция EXIT WHEN обеспечивает выход из цикла при выполнении условия, а закрывающая операторная скобка END LOOP завершает цикл.
Пример. Оператор WHILE
DECLARE X number; I number; Limit number:=1000; BEGIN I:=0; X:=0; WHILE I <= Limit LOOP I:=I+1; X:=X+I*I; END LOOP; DBMS_OUTPUT.PUT_LINE (x); END; /
Управление потоком команд типа WHILE обеспечивает выполнение цикла до тех пор, пока условие является истинным.
Пример. Оператор FOR
DECLARE X number; Limit number:=1000; BEGIN I:=0; X:=0; FOR I IN 0..Limit LOOP X:=X+I*I; END LOOP; DBMS_OUTPUT.PUT_LINE (x); END; /
Цикл, управляемый оператором FOR, используется, когда точно известно, сколько раз нужно выполнить операторы цикла. Переменную цикла описывать в блоке DECLARE не нужно.
Определение хранимых процедур и функций в PL/SQL
Процедура или функция PL/SQL имеет уникальное имя. Как и программы на PL/SQL, процедуры и функции имеют блок объявлений, блок исполняемого кода и, опционально, блок обработки исключительных ситуаций. Но процедура может принимать и возвращать значения параметром, а функция дополнительно возвращает значение.Описание процедуры имеет следующий синтаксис:
PROCEDURE имя [(параметр [, параметр, ...])] IS [объявление локальных переменных, пользовательских типов данных, пользовательских исключительных ситуаций, локальных подпрограмм и функций] BEGIN Исполняемый код [EXCEPTION обработчики исключительных ситуаций] END [имя];
Параметры процедуры обеспечивают входные и выходные данные процедуры. Параметров у процедуры может и не быть, так что этот раздел не является обязательным. Для задания параметров используется следующий синтаксис:
Имя параметра [IN | OUT | IN OUT] тип данных [{:= | DEFAULT} выражение]
В определении параметров нельзя использовать ограничение NOT NULL, а в определении типа данных нельзя использовать никакие ограничения. Для каждого параметра должен быть указан его тип (parameter mode) - IN, OUT или IN OUT. Указание типа IN означает, что значение параметра определяется при обращении к процедуре и не изменяется процедурой. Попытка изменить такой параметр в теле процедуры приведет к возникновению ошибки. Указание типа OUT предполагает изменение значения параметра в процессе выполнения процедуры, т.е. это возвращаемый параметр. Указание типа IN OUT говорит о том, что при вызове процедуры такому параметру должно быть присвоено значение, которое может быть изменено в теле процедуры. Типом по умолчанию считается IN. Ниже в таблице 12.2 суммирована информация о типах параметров.
| Умолчание | Должен быть задан | Должен быть задан |
| Передает значение в процедуру или функцию | Возвращает значение из процедуры или функции | Передает значение в процедуру или функцию и возвращает измененное значение |
| Формальный параметр действует как константа | Формальный параметр действует как неинициализированная переменная | Формальный параметр действует как неинициализированная переменная |
| Формальному параметру не может быть присвоено значение | Формальный параметр не может быть использован в выражении, и ему должно быть присвоено значение | Формальному параметру можно присваивать значение |
| Действительный параметр может быть константой, инициализированной переменной, литеролом или выражением | Действительный параметр должен быть переменной | Действительный параметр должен быть переменной |
Определение процедуры начинается с ключевого слова PROCEDURE и заканчивается именем процедуры или списком параметров. Тело процедуры начинается с ключевого слова IS и заканчивается ключевым словом END. Тело процедуры состоит из трех частей, которые отвечают блокам программы PL/SQL.
Пример. Для нашей учебной базы данных можно рассмотреть вопрос о создании процедуры, которая увеличивает зарплату сотрудника по значению его номера.
PROCEDURE raise_salary (empid INTEGER, increase REAL) IS current_salary REAL; salary_missing EXCEPTION; BEGIN SELECT sal INTO current_salary FROM employee WHERE empno = emp_id; IF current_salary IS NULL THEN RAISE salary_missing; ELSE UPDATE employee SET sal = sal + increase WHERE empno = emp_id; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN INSERT INTO emp_audit VALUES (emp_id, 'Нет сотрудника с таким номером'); WHEN salary_missing THEN INSERT INTO emp_audit VALUES (emp_id, Зарплата не назначена'); END raise_salary;
При вызове процедура принимает номер сотрудника и величину прибавки к зарплате в качестве параметров. Номер сотрудника используется далее для выборки значения текущей зарплаты из таблицы EMPLOYEE в локальную переменную current_salary. Если номер сотрудника не найден в базе данных или значение зарплаты не установлено, то возникают исключительные ситуации, стандартная и определенная пользователем соответственно. В противном случае зарплата обновляется.
Процедура вызывается как команда PL/SQL
raise_salary (emp_num, amount);
В примере использована вспомогательная таблица базы данных emp_audit для отслеживания возникновения ошибочных ситуаций при работе с базой данных.
Рассмотрим еще один пример использования процедуры для выборки зарплаты служащего по его фамилии из таблицы EMPLOYEE учебной базы данных.
PROCEDURE emp_salary (sName INTEGER, sal_p OUT REAL) IS current_salary REAL; salary_missing EXCEPTION; BEGIN SELECT sal INTO current_salary FROM employee WHERE ENAME=:sName'; IF current_salary IS NULL THEN RAISE salary_missing; ELSE sal_p = current_salary END IF; EXCEPTION WHEN NO_DATA_FOUND THEN INSERT INTO emp_audit VALUES (emp_id, 'Нет сотрудника с такой фамилией'); WHEN salary_missing THEN INSERT INTO emp_audit VALUES (emp_id, Зарплата не назначена'); END raise_salary;
Определение процедуры начинается с ключевого слова PROCEDURE и заканчивается именем процедуры или списком параметров. Тело процедуры начинается с ключевого слова IS и заканчивается ключевым словом END. Тело процедуры состоит из трех частей, которые отвечают блокам программы PL/SQL.
Пример. Для нашей учебной базы данных можно рассмотреть вопрос о создании процедуры, которая увеличивает зарплату сотрудника по значению его номера.
PROCEDURE raise_salary (empid INTEGER, increase REAL) IS current_salary REAL; salary_missing EXCEPTION; BEGIN SELECT sal INTO current_salary FROM employee WHERE empno = emp_id; IF current_salary IS NULL THEN RAISE salary_missing; ELSE UPDATE employee SET sal = sal + increase WHERE empno = emp_id; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN INSERT INTO emp_audit VALUES (emp_id, 'Нет сотрудника с таким номером'); WHEN salary_missing THEN INSERT INTO emp_audit VALUES (emp_id, Зарплата не назначена'); END raise_salary;
При вызове процедура принимает номер сотрудника и величину прибавки к зарплате в качестве параметров. Номер сотрудника используется далее для выборки значения текущей зарплаты из таблицы EMPLOYEE в локальную переменную current_salary. Если номер сотрудника не найден в базе данных или значение зарплаты не установлено, то возникают исключительные ситуации, стандартная и определенная пользователем соответственно. В противном случае зарплата обновляется.
Процедура вызывается как команда PL/SQL
raise_salary (emp_num, amount);
В примере использована вспомогательная таблица базы данных emp_audit для отслеживания возникновения ошибочных ситуаций при работе с базой данных.
Рассмотрим еще один пример использования процедуры для выборки зарплаты служащего по его фамилии из таблицы EMPLOYEE учебной базы данных.
PROCEDURE emp_salary (sName INTEGER, sal_p OUT REAL) IS current_salary REAL; salary_missing EXCEPTION; BEGIN SELECT sal INTO current_salary FROM employee WHERE ENAME=:sName'; IF current_salary IS NULL THEN RAISE salary_missing; ELSE sal_p = current_salary END IF; EXCEPTION WHEN NO_DATA_FOUND THEN INSERT INTO emp_audit VALUES (emp_id, 'Нет сотрудника с такой фамилией'); WHEN salary_missing THEN INSERT INTO emp_audit VALUES (emp_id, Зарплата не назначена'); END raise_salary;
Особенности использования процедур и функций в СУБД Oracle
В этом подразделе рассмотрим некоторые особенности использования процедур и функций в PL/SQL:При вызове процедур и функций в PL/SQL допускается передача параметров по имени и по позиции. Это означает, что вы указываете, как происходит связывание формальных и действительных параметров. Например, пусть имеется гипотетическая программа
DECLARE x1 INTEGER; x2 REAL; PROCEDURE proc1 (p1 INTEGER, p2 REAL) IS BEGIN ... END;
Процедуру Proc1 можно вызвать следующими эквивалентными способами:
BEGIN ... proc1 (x1, x2); -- передача параметров по позиции proc1 (p2 => x2, p1 => x1); -- передача параметров по имени proc1 (p1 => x1, p2 => x2); -- передача параметров по имени proc1 (x1, p2 => x2); -- передача параметров и по -- позиции, и по имени END;
При передаче параметра по позиции компилятор PL/SQL последовательно связывает первый фактический параметр с первым формальным параметром, второй фактический параметр - со вторым формальным параметром и так далее.
При передаче параметра по имени стрелка, называемая оператором связывания (association operator), связывает формальный параметр слева от стрелки с фактическим параметром справа от стрелки, причем порядок следования таких пар не имеет значения.
Можно комбинировать передачу параметра по позиции и по имени. Но при этом следует соблюдать требование того, чтобы передача параметра по позиции предшествовала передаче параметра по имени.
В процедуре или функции можно инициализировать параметр типа IN значением по умолчанию. Таким способом можно передавать различное число действительных параметров в процедуры или функции, принимая или переопределяя значение по умолчанию. Рассмотрим пример.
Пример. Для нашей учебной базы данных разработаем процедуру создания нового отдела таблице DEPARTAMENT.
PROCEDURE create_dept (new_dname CHAR DEFAULT 'Новый', new_loc CHAR DEFAULT 'Москва') IS BEGIN INSERT INTO departament VALUES (deptno_seq.NEXTVAL, new_dname, new_loc); END create_dept;
Если при вызове процедуры фактический параметр не передается, то используется значение по умолчанию. Рассмотрим следующие вызовы этой процедуры:
create_dept; create_dept('Маркетинг'); create_dept('Маркетинг', Черноголовка);
При первом вызове не передается никаких параметров, так что используются значения параметра по умолчанию - Новый отдел в г. Москве. Во втором вызове передается один параметр - первый. Для второго используется значение по умолчанию. В третьем случае передаются оба параметра и значения по умолчанию не используются.
Для оптимизации выполнения процедур и функций компилятор PL/SQL может выбирать различные методы передачи параметров (по значению или по ссылке) для различных параметров в одном и том же вызове процедуры или функции. Когда компилятор выбирает метод передачи параметра по значению, то его значение копируется в процедуре или функции. Когда компилятор выбирает метод передачи параметра по ссылке, то адрес фактического параметра передается в процедуру или функцию. Может создаться ситуация когда переменная в процедуре или функции будет иметь два имени - так называемая проблема алиасных имен. В этом случае результат будет неопределенным. Это происходит, когда глобальная переменная передается по адресу, как в примере ниже.
Пример
DECLARE rent REAL; PROCEDURE raise_rent (increase IN OUT REAL) IS BEGIN rent := rent + increase; -- в случае передачи параметра по адресу -- одна и та же переменная будет иметь два имени. END raise_rent; BEGIN ... raise_rent(rent); -- indeterminate
Такая ситуация может также возникнуть, когда фактическая переменная дважды передается в процедуру или функцию. Если оба формальных параметра имеют тип IN, то результат не определен.
Пример. Рассмотрим процедуру реверсирования строки.
DECLARE str VARCHAR2(10); PROCEDURE reverse (in_str VARCHAR2, out_str OUT VARCHAR2) IS BEGIN ... END reverse; ... BEGIN str := 'abcd'; reverse(str, str); -- Не определен
Результат выполнения процедуры будет зависеть от выбранного компилятором способа передачи параметра в процедуру.
Компилятор PL/SQL позволяет также перезагружать (overload) имена процедур и функций, т.е. вы можете использовать одно и то же имя для нескольких различных процедур или функций. При этом число параметров, их порядок и типы данных могут быть различными.
Таким образом, основными преимуществами использования процедур и функций в базах данных являются:
Создание хранимых процедур и функций
Хранимая процедура или функция есть объект реляционной базы данных, который является поименнованным набором операторов SQL и, в случае СУБД Oracle, набором операторов PL/SQL, который может быть скомпилирован и необязательно сохранен в базе данных. Если процедура сохраняется в базе данных, то она называется хранимой процедурой или функцией. Описание хранимых процедур и функций хранится в словаре данных реляционной базы данных.Обычно хранимые процедуры используются для выполнения набора типовых действий, характерных для достижения целей создания базы данных, а хранимые функции - для вычисления значений.
Код хранимых процедур и функций хранится в базе данных. Поэтому использование хранимых процедур и функций для выполнения типовых операций, характерных для приложения базы данных, приводит к упрощению приложений за счет передачи обработки на сервер базы данных. Такой подход уменьшает накладные расходы за счет сокращения фазы синтаксического анализа и уменьшения времени передачи запроса на конкретное действие по вычислительной сети, что приводит в целом к снижению трафика сети. Обычно при этом улучшается производительность, но это необязательно для маломощных серверов баз данных.
Хранимые процедуры и функции, как объекты базы данных, создаются командой CREATE и уничтожаются командой DROP. Команда создания хранимой процедуры имеет следующий синтаксис:
CREATE [OR REPLACE] PROCEDURE [имя схемы].имя процедуры [имя [(параметр [, параметр, ...])] {IS|AS} программа на PL/SQL;
Ключевое слово OR REPLACE указывает на безусловное замещение старого текста процедуры. Если процедура с таким именем уже определена, но ключевое слово OR REPLACE не указано, то возвращается сообщение об ошибке и замещения старого текста не происходит.
При описании переменных хранимой процедуры ключевое слово DECLARE не используется. Блок описания переменных начинается сразу после ключевого слова IS или AS.
Пример.
PROCEDURE create_dept (new_dname CHAR, new_loc CHAR) IS BEGIN INSERT INTO dept VALUES (deptno_seq.NEXTVAL, new_dname, new_loc); END create_dept;
Исполнение созданной процедуры может быть выполнено оператором EXEC PL/SQL, как показано ниже:
EXEC ;
Команда создания хранимой процедуры имеет следующий синтаксис:
CREATE [OR REPLACE] FUNCTION [имя схемы].имя функции [имя [(параметр [, параметр, ...])] RETURN тип данных {IS|AS} программа на PL/SQL;
Как можно увидеть, синтаксис команды создания хранимой функции похож на синтаксис команды создания хранимой процедуры, за исключением того, что в описании функции используется предложение RETURN. Описание типа данных для возвращаемого значения требуется обязательно.
Пример. Для нашей учебной базы данных создадим функцию, которая считает число сотрудников, поступивших в организацию за определенный период:
CREATE OR REPLACE FUNCTION emp_cnts (data1 IN date, data2 IN date) RETURN Integer IS I_count number:=0; BEGIN SELECT COUNT(*) INTO i_count FRON employee WHERE hiredate BETWEEN date1 AND date2; RETURN i_count; END;
Вызвать созданную хранимую функцию можно следующим образом:
EXEC DBMS_OUTPUT.PUT_LINE(emp_cnts('01-may-02', ''01-jul-02'));
Для уничтожения хранимой процедуры или функции в базе данных используется команда DROP в формате DROP [имя схемы].имя процедуры;
Или
DROP [имя схемы].имя функции;
Создание пакетов PL/SQL
Процедуры, функции и глобальные переменные, объединенные общим функциональным замыслом, часто оформляются в виде специального объекта базы данных - пакета. Прием оформления родственных программ в пакет хорошо известен из программистской практики. Особенностью PL/SQL является раздельная компиляция и хранение интерфейсной и исполнительной частей пакета. Таким образом, пакет (package) есть объект базы данных, который группирует логически связанные типы, объекты, процедуры и функции PL/SQL. Пакет состоит из двух частей: спецификации пакета и тела пакета, хотя тело пакета иногда опускается. Спецификация пакета есть интерфейс для вашего приложения. В ней хранится описание процедур, функций, глобальных переменных, констант и курсоров, которые доступны из внешних приложений. Тело пакета полностью определяет курсоры, процедуры и функции, являясь, таким образом, реализацией спецификации. В теле пакета могут также быть определены переменные, курсоры, процедуры и функции. Они являются локальн ыми, т.е. не доступными из внешних приложений.Синтаксис определения пакета в базе данных состоит также из двух частей. Оператор создания интерфейсной части имеет следующий синтаксис:
CREATE [OR REPLACE] PACKAGE [имя схемы].имя AS Определения типов и объектов Спецификации процедур и функций END [имя];
Ключевое слово OR REPLACE указывает на безусловное замещение предыдущего кода спецификации пакета. Если оно не указано, а пакет определен в базе данных, то замещения старого значения спецификации пакета не происходит и возвращается сообщение об ошибке.
Спецификация пакета начинается с объявления констант и переменных, при этом ключевое слово DECLARE не используется. Рассмотрим пример создания спецификации пакета.
Пример
CREATE OR REPLACE PACKAGE paket1 AS A1 CONSTANT number:= 1.3; PROCEDURE Pr1; FUNCTION F01 (x1 real) RETURN real; END; /
Оператор создания тела пакета имеет следующий синтаксис:
CREATE [OR REPLACE] PACKAGE BODY [имя схемы].имя AS Объявления локальных типов и переменных Тела процедур и функций [BEGIN команды инициализации END [имя];
Ключевое слово OR REPLACE указывает на безусловное замещение предыдущего кода тела пакета. Если оно не указано, а пакет определен в базе данных, то замещения старого значения тела пакета не происходит и возвращается сообщение об ошибке.
Рассмотрим пример создания тела пакета для спецификации, определенной в предыдущем примере.
Пример. Пусть функция пакета F01 умножает аргумент на заданное число, а процедура Pr1 фиксирует факт обращения к функции пакета в таблице базы данных. Предполагается, что таблица T01 уже существует.
CREATE OR REPLACE PACKAGE BODY paket1 AS Cnt number:=0; FUNCTION F01(x1 real) RETURN real IS BEGIN Pr1; RETURN x1*A1; END; PROCEDURE Pr1 IS BEGIN Cnt:=Cnt+1; INSERT INTO T01 VALUES(Cnt,SYSDATE); COMMIT; END; END; /
Отметим, что инициализация локальных переменных, таких как переменная Cnt примера, происходит при запуске сервера СУБД Oracle.
Константа или переменная, определенная в спецификации пакета, может быть доступна из пользовательской программы, при условии, если такой доступ разрешен администратором базы данных. Чтобы обратиться к глобальной переменной или константе пакета, нужно использовать квалифицируемое имя, указав в качестве префикса к имени переменной или константы имя пакета. Аналогично происходит обращение к процедурам или функциям пакета, определенных в спецификации пакета. Например,
package_name.type_name package_name.object_name package_name.subprogram_name
Чтобы уничтожить пакет для освобождения ресурсов сервера, используется команда SQL DROP в следующем формате:
DROP PACKAGE [BODY] [имя схемы].имя пакета;
Необязательное ключевое слово BODY указывает, что уничтожается только тело пакета, в противном случае удаляется и спецификация, и тело пакета.
Что дает проектировщику базы данных использование пакетов? Пакеты обладают рядом преимуществ, к которым принято относить следующие:
Использование пакетов позволяет проектировщику базы данных сделать приложения проще, яснее и хорошо определенными. Поскольку каждый пакет в отдельности проще для понимания, связи между пакетами через хорошо определенные интерфейсы яснее и проще.
Рассмотрим для нашей учебной базы данных пример принятия решений проектировщиком базы данных о создании пакета.
Предположим, что в организации высокая степень текучести кадров. Пользователь базы данных, который работает с персоналом, проводит одну сессию работы с базой данных в начале недели.
В рамках этой сессии он фиксирует в базе данных новых сотрудников, которые приступают к работе с понедельника (бизнес-правило организации - принимать на работу только с понедельника), и удаляет информацию о сотрудниках из базы данных (бизнес-правило организации - не сохранять информацию об уволенном сотруднике в базе данных), которые ушли из организации. Тогда проектировщик базы данных может рассмотреть создание пакета, содержащего две процедуры: одну для занесения информации о сотруднике в базу данных, а другую - для удаления информации о сотруднике из базы данных. Код пакета может быть таким, как показано ниже.
CREATE PACKAGE emp_actions AS TYPE EmpRecTyp IS RECORD (emp_id INTEGER, salary REAL); CURSOR desc_salary RETURN EmpRecTyp; PROCEDURE hire_employee ( ename VARCHAR2, job VARCHAR2, mgr NUMBER, sal NUMBER, comm NUMBER, deptno NUMBER); PROCEDURE fire_employee (emp_id NUMBER); END emp_actions;
CREATE PACKAGE BODY emp_actions AS CURSOR desc_salary RETURN EmpRecTyp IS SELECT empno, sal FROM employee ORDER BY sal DESC; PROCEDURE hire_employee ( ename VARCHAR2, job VARCHAR2, mgr NUMBER, sal NUMBER, comm NUMBER, deptno NUMBER) IS BEGIN INSERT INTO employee VALUES (empno, ename, job, mgr, SYSDATE, sal, comm, deptno); END hire_employee; PROCEDURE fire_employee (emp_id NUMBER) IS BEGIN DELETE FROM employee WHERE empno = emp_id; END fire_employee; END emp_actions;
Создание триггеров PL/SQL
Триггер базы данных (database trigger) является объектом реляционной базы данных, который активизирует выполнение хранимой (или встроенной) PL/SQL-процедуры при изменении пользователем данных в таблице. Событие, управляющее запуском триггера, описывается в виде логических условий. Например, попытка модифицировать данные в таблице активизирует триггер, соответствующий данной команде манипулирования данными. Число триггеров на таблицу базы данных не ограничено.Обычно триггеры используют для реализации ограничений ссылочной целостности, для предотвращения несогласованных изменений в базе данных (поддержка целостности базы данных), для выполнения скрытых операций при модификации, а также для снижения сетевого трафика за счет передачи обработки на сервер. Операции завершения транзакции выполняются после обработки триггеров.
При выполнении команды UPDATE с помощью триггера можно проверить, что модифицируемые данные удовлетворяют ограничениям целостности базы данных до выполнения операции (при этом возможен доступ к новым данным!). После выполнения операции с помощью триггера можно выполнить скрытую обработку данных с учетом поступивших изменений (старые данные также могут быть доступны).
При выполнении команды INSERT также можно проверить данные до вставки в таблицу на допустимость ограничениям целостности, а после - выполнить операции над только что вставленными данными.
При выполнении команды DELETE можно проверить данные до их удаления или восстановить данные после удаления.
Для создания триггера предусмотрена специальная команда SQL CREATE TPIGGER. Эта команда создает триггер на таблице, которой владеет пользователь. Невозможно создать триггер для виртуальной таблицы.
Синтаксис команды следующий:
CREATE [OR REPLACE] TPIGGER [имя схемы.]имя триггера {BEFORE|AFTER} {INSERT|DELETE|UPDATE [OF имя колонки [, имя колонки ѕ]]} [OR {INSERT|DELETE|UPDATE [OF имя колонки [, имя колонки ѕ]]}] ON [имя схемы.]{имя таблицы|имя представления} {FOR EACH ROW][WHEN условие] спецификация пакета на PL/SQL
Ключевое слово OR REPLACE указывает на безусловное замещение старого теста триггера. Если оно не указывается, а триггер определен в базе данных, то замещения старого триггера не происходит, и возвращается сообщение об ошибке.
Определение триггера состоит из нескольких частей:
Если имя схемы опущено, то триггер создается в схеме текущего пользователя.
Первая часть - это указание команды, которая запускает триггер. При создании триггера необходимо указывать, к какой команде манипулирования данными он относится - INSERT, DELETE или UPDATE. Для последней модно указывать конкретные колонки, указав фразу OF имя_колонки [, имя_колонки ...] в предложении UPDATE.
Ключевое слово ON задает имя таблицы или представления, для которого создается триггер.
Ограничения триггера указывают дополнительные условия, которые должны удовлетворяться для строки, чтобы триггер запустился.
Триггер имеет время действия - до или после выполнения команды манипулирования данными, - которое задается ключевыми словами BEFORE или AFTER, соответственно. Обычно нельзя определить два триггера на одну и ту же операцию с одинаковым временем действия.
Необязательное ключевое слово ON EACH ROW определяет триггер как строчный, т.е. запускаемый для каждой строки результирующего множества команды SQL. Если оно опущено, то триггер запускается только один раз в начале обработки команды. Таким образом, условие "для каждой строки" активизируется, только когда есть строки (например, предложение WHERE дает истинное значение условий поиска), в то время как для условия "для каждой команды" триггер сработает и в этом случае.
Дополнительные условия, сужающие область действия триггера, могут быть заданы в предложении WHEN. Условия, задаваемые в этом предложении, являются стандартными для SQL условиями, должны содержать корреляционные имена и не могут содержать запрос.
Это предложение может быть указано только для строчного триггера.
Действие, которое выполняет триггер, задается в теле триггера блоком кода PL/SQL, который не может содержать команд управления транзакциями, таких как COMMIT, ROLLBACK и SAVEPOINT.
Для того чтобы задать корреляционные имена, т.е. чтобы видеть старые и новые значения колонок при обновлении, нужно воспользоваться предложением REFERENCING OLD AS имя_таблицы_старых_значений NEW AS имя_таблицы_новых_значений. Определяемые имена являются псевдонимами для обновляемой таблицы и должны быть различны. На эти имена можно ссылаться в теле триггера. По умолчанию корреляционные имена есть OLD и NEW для старого и нового значения строки.
С каждым триггером можно связать его тип. Тип триггера определяется следующими условиями:
Таким образом, тип триггера определяется всевозможными комбинациями ключевых слов BEFORE, AFTER и FOR EACH ROW, что дает четыре основных типа триггера, как показано в таблице 12.3 ниже.
| BEFORE | BEFORE: СУБД запускает триггер до выполнения команд | BEFORE: СУБД запускает триггер до модификации каждой строки, обрабатываемой командой |
| AFTER | AFTER: СУБД запускает триггер после выполнения команды | AFTER: СУБД запускает триггер после модификации каждой строки, обрабатываемой командой |
Пример
CREATE TRIGGER emp_permit_changes BEFORE DELETE OR INSERT OR UPDATE ON employee DECLARE dummy INTEGER; BEGIN /* Если сегодня суббота или воскресенье, то ошибка. */ IF (TO_CHAR(SYSDATE, 'DY') = 'SAT' OR TO_CHAR(SYSDATE, 'DY') = 'SUN') THEN raise_application_error( -20501, 'Можно изменять таблицу employee только в рабочие дни'); END IF; /* Если праздник, то тоже ошибка */ SELECT COUNT(*) INTO dummy FROM company_holidays WHERE day = TRUNC(SYSDATE); IF dummy > 0 THEN raise_application_error( -20501, 'Нельзя изменять таблицу employee по праздникам'); END IF; /* Если текущее время меньше 8:00 часов утра или 5:00 часов вечера, то ошибка */ IF (TO_CHAR(SYSDATE, 'HH24') < 8 OR TO_CHAR(SYSDATE, 'HH24') >= 17) THEN raise_application_error( -20502, 'Нельзя изменять таблицу employee в нерабочие часы'); END IF; END;
Структура программы на PL/SQL
Модельным прототипом для создания языка PL/SQL послужил язык программирования ADA, поэтому он обладает набором средств, характерных для любого современного языка программирования. Всякая программа на PL/SQL состоит из трех блоков: блока описаний, блока исполняемого кода и блока обработки исключительных ситуаций. Блок исполняемого кода может быть структурирован с помощью операторных скобок BEGIN … END.Синтаксически программа на PL/SQL оформляется следующим образом:
DECLALE Описание переменных и констант BEGIN Операторы EXCEPTION Операторы END;
Перед блоком DECLALE могут располагаться команды установки переменных окружения. В блоке DECLALE описываются константы, переменные и определенные пользователем типы данных. Первый оператор BEGIN отмечает начало тела основной программы. В тело программы могут быть включены другие блоки, ограниченные операторными скобками. Блок EXCEPTION определяет фрагменты программного кода для обработки исключительных ситуаций в программе. Последний оператор END указывает конец тела программы. В любые части программы могут быть включены комментарии, т.е. текст, который начинается с символов -- и продолжается до конца текущей строки. Строка, начинающаяся с ключевого слова REM, также рассматривается как комментарий.
Основы проектирования реляционных баз данных
Формулы для оценки размера БД
С целью упрощения вычислений размера базы данных, в настоящем разделе мы будем проводить вычисления на примере СУБД SQLBASE. Размер базы данных может быть оценен по формуле
Перед тем как вычислить размер таблицы, необходимо вычислить размеры всех ее колонок.
Вычисление размера колонки. Вычисление размера колонки зависит от типа домена колонки. Размер колонки или столбца таблицы - это число символов, которое отводится СУБД для хранения колонки заданного типа.
Как правило, в определении таблицы задаются максимальные размеры полей указанного типа для данной предметной области. Например, предполагается, что колонка адреса компании не будет занимать более 50 символов. С другой стороны, на практике, на реальных данных средний размер колонки адреса компании может составлять 30 символов. Расчет размера базы данных целесообразно проводить исходя из среднего размера колонок таблиц.
Типичные размеры колонок заданного типа приведены в таблице 13.2 ниже.
| Character | Число символов в строке |
| Number | [(NumberOfDigits + 2)/ + 1 байт |
| Date | 5 байт |
| DateTime | 12 байт |
| Long varchar | 12 байт плюс число сраниц для хранения данных |
Размер строки таблицы определяется как сумма размеров всех ее колонок по формуле
Data _ Length =
всех _ длин _ колонокВычисление размера таблицы. Основываясь на значении Data_Length можно оценить размер обычной таблицы или хэш-таблицы. Формулы для выполнения такой оценки приведены в таблицах 13.3 и 13.4. Различие в методике расчета размера хэш-таблицы заключается в необходимости учитывать параметр загрузки хэш-таблицы (packing_density), который устанавливается при определении такой таблицы.
| Row_Lenght | Длина строки на физической странице включает в себя длину заголовка и размер строки таблицы, которая вычисляется по формуле Row_Lenght = 18 + (2 * число_колонок) + Data_Lenght |
| Row_Lenght_with_Stack | Длина строки с размером стека Row_Lenght_with_Stack = Row_Lenght * 100 (100 - PCTFREE) |
| Usable_Row_Page_Size | Используемая СУБД длина строки на странице. В SQLBASE длина заголовка страницы равна 86 байт Usable_Row_Page_Size = 1024 - 86 = 936 байт |
| Rows_per_Page | Число строки на страницу: Rows_per_Page = [Usable_Row_Page_Size / Row_Lenght_with_Stack] |
| Nbr_Row_Pages | Число строк на странице: Nbr_Row_Pages = [NbrOfRows / Rows_per_Page],где NbrOfRows - предполагаемое число строк в таблице |
| Nbr_Long_Pages | Число страниц, занимаемых длинными строками: Nbr_Long_Pfge = NbrOfRows * Nbr_Long_Pages_per_Long_Col, Nbr_Long_Pages_per_Long_Col - число длинных строк на страницу |
| Total_Data_Page | Число страниц данных: Total_Data_Page = Nbr_Row_pages + Nbr_Long_Pages |
table class="xml_table" cellpadding="2" cellspacing="1">
Таблица 13.4. Оценки размера хэш-таблицы
| Key_Lenght | Длина ключа равна сумме средних длин колонок, которые составляют данный ключ |
| Index_Entry_Lenght | Длина размера строки индекса: Index_Entry_Lenght = 9 + число_колонок_ключа_индекса + Key_Lenght |
| Usable_Index_Page_Size | Используемый СУБД размер страницы индекса: Usable_Index_Page_Size = (1024 - 74)* (100 - PCTFREE)/100 |
| Index_Entry_per_Page | Число входов индекса на страницу: Index_Entry_per_Page = [Usable_Index_Page_Size / Index_Entry_Lenght |
| Nbr_Index_Pages | Число страниц, занимаемых индексом Nbr_Index_Pages = [NbrOfRows / Index_Entry_per_Page], где NbrOfRows - предполагаемое число строк в таблице |
Вычисление размера заголовка представления. Для каждого представления существует фиксированная часть заголовка и переменная часть заголовка, которая зависит от его сложности. Формулы для расчета размера заголовка представления приведены в таблице 13.6.
| Fixed_Overhead | = 12 * 1024 |
| Variable_Overhead | = 150 * число_таблиц + 170 * число_колонок |
| Variable_Overhead_all_Views |  Variable_Overhead для всех представлений |
| Total_View_overhead_in_Page | = [(Fixed_Overhead + Variable_Overhead + Variable_Overhead_all_Views)/1024] |
Total_Fixed_Overhead_Pages = 12*число_таблиц + 2*число_хэш_индексов + 602112/1024
Назначение привилегий
С каждой учетной записью связана так называемая область привилегий, которая остается пустой при создании ее с помощью команды CREATE USER.Привилегия - это поддерживаемый системой признак, который определяет, может ли конкретный пользователь выполнить конкретную операцию, т.е. разрешение на выполнение в системе определенного действия. Таким образом, имеется несколько типов привилегий, соответствующих нескольким типам операций, и, следовательно, предполагается, что пользователь в системе будет обладать определенным набором привилегий.
Для понимания действия этого механизма определения привилегий важно понятие владельца таблицы. Будучи пользователем, определенным в базе данных, вы являетесь владельцем любой созданной вами таблицы. Вы можете разрешить доступ к вашей таблице другим пользователям, определяя им привилегии прав доступа к своим таблицам.
Множество базовых привилегий определено стандартом ANSI SLQ, но, как правило, в конкретных СУБД поддерживаются дополнительные типы привилегий. Например, в СУБД Oracle их около сотни.
Все привилегии могут быть разделены на два класса: системные привилегии и привилегии прав доступа к объектам базы данных.
Системная привилегия - это привилегия, которая дает пользователю право на выполнение какой-либо операции в масштабе базы данных. Например, привилегия SELECT ANY TABLE дает пользователю право выполнять выборку из любой таблицы базы данных.
Привилегия прав доступа к объекту - это разрешение пользователю на выполнение определенной операции над определенным объектом базы данных. Например, пользователю может быть предоставлена привилегия SELECT на выполнение выборки из конкретной таблицы.
Для предоставления привилегий или, как еще говорят, авторизации доступа в SQL предусмотрена команда GRANT - ее может выполнить обычно только системный администратор, который предопределен в системе как SYSADM (наивысший уровень доступа, при котором возможно выполнение всех операций над БД). В СУБД Oracle такой пользователь должен обладать привилегией GRANT ANY RPIVILEGE.
Команда GRANT для определения системных привилегий имеет следующий синтаксис:
GRANT системная_привилегия [ { , системная_привиления } ѕ] TO { пользователь | PUBLIC } [{, пользователь} ѕ ] [WITH ADMIN OPTION]
В СУБД Oracle привилегии прав доступа к объекту могут быть предоставлены двум объектам системы: пользователям и ролям. Роль представляет собой поименованный набор привилегий. Предложения команды GRANT в данном случае управляют разграничением доступа к объектам базы данных: таблицам, представлениям, процедурам и т.д. Синтаксис команды имеет вид
GRANT {привилегия_доступа_к_объекту | ALL PRIVILEGES} [ имя_столбца [{ , имя_столбца } ѕ] ] [{ , привилегия_доступа_к_объекту } ѕ ] ON [имя_схемы.]имя_объекта TO { пользователь | PUBLIC } [WITH GRANT OPTION]
Список привилегий доступа показан в таблице 13.1 ниже.
| SELECT | Выполнение вставки данных из соответствующего объекта |
| INSERT | Выполнение вставки данных в соответствующий объект или его элемент |
| UPDATE | Выполнение модификации данных в соответствующем объекте или его элементе |
| REFERENCES | Определение столбцов как родительских ключей по отношению к внешним ключам в таблицах, ссылки, по которой производится контроль целостности объекта или егоэлемента |
| DELETE | Выполнение удаления данных из соответствующего объекта |
| EXECUTE | Выполнение действия с соответствующим объектом, например, вызов процедуры |
| INDEX | Выполнение индексирования для соответствующего объекта |
GRANT SELECT ON EMPLOYEE TO PETROV;
Вы можете также дать привилегии на выполнение обновления, добавления, удаления данных в таблицах и виртуальных таблицах (UPDATE, INSERT, DELETE), а также для изменения структуры таблицы (ALTER) и право на использование индекса (INDEX).
При определении привилегии на обновление вы можете указать список колонок, обновлять которые вы разрешаете другим пользователям таблицы.
Можно разрешить доступ на выборку таблицы и группе пользователей. Допустим, что вы желаете разрешить доступ к таблице EMPLOYEE всем пользователям, но исключить при этом доступ к колонкам SAL, COMM и FINE. Хорошим решением в данном случае будет создать виртуальную таблицу и разрешить доступ к ней всем пользователям:
CREATE VIEW EMP AS SELECT EMPNO,ENAME,JOB,AGE,HIREDATE,DEPNO FROM EMPLOYEE;
Теперь вы можете разрешить доступ всем пользователям к созданной виртуальной таблице, используя ключевое слово PUBLIC.
GRANT SELECT ON EMP TO PUBLIC;
Вы можете организовать и более сложные механизмы защиты данных. Например, вы можете, используя виртуальные таблицы, ограничить доступ к данным таблицы EMPLOYEE руководителям подразделений таким образом, что они не будут иметь доступа к информации по другим подразделениям. При этом удобно воспользоваться ключевым словом USER для идентификации пользователя:
CREATE VIEW EMPDEPT AS SELECT * FROM EMPLOYEE WHERE DEPNO IN ( SELECT DEPNO FROM EMPLOYEE WHERE ENAME = USER );
Теперь вы можете определить привилегии доступа для всех руководителей организации:
GRANT SELECT,UPDATE ON EMPDEPT TO IVLEV
Для отмены привилегий доступа в SQL предназначена команда REVOKE. Эта команда, так же как и команда GRANT, включает предложения ON и TO. Предложение REVOKE определяет отменяемую привилегию. Чтобы отменить привилегии на добавление строк в таблицу пользователю PETROV, нужно выполнить команду
REVOKE INSERT ON DEPARTAMENT TO PETROV;
Оценка размера базы данных
Базы данных существуют и функционируют в конкретной программно-аппаратной среде. Компьютер представляет собой аппаратную среду, состоящую из множества различных компонент - центрального процессора, оперативной и внешней памяти и т.д. Для обеспечения взаимодействия аппаратных компонент служит операционная система. Операционные системы варьируются в зависимости от используемой аппаратуры. Операционная система представляет собой промежуточный уровень между компьютерной аппаратурой и программами. СУБД - это программа для поддержки базы данных. База данных хранится в файлах операционной системы, которые располагаются во внешней памяти компьютера, на жестких дисках. Файлы операционной системы обычно располагаются внутри логически поименованных областей жесткого диска, которые называются каталогами. Приложения базы данных взаимодействуют с данными в ней через цепочку программных взаимодействий:
.Размер базы данных во многих практических ситуациях является критическим параметром ее эксплуатации. Проектировщик БД должен уметь оценивать как размер БД, так и возможный ее рост во времени.
Отправной точкой решения задачи оценки размера БД является вычисление размера каждой таблицы БД. Чтобы это сделать, необходимо вычислить размер каждой колонки в таблице и на основании этих данных оценить размер самой таблицы. Далее следует оценить размер всех индексов, представлений и других объектов.
Поскольку ОС распределяет память под файлы в страницах, то при вычислении размера базы данных необходимо оценить число страниц, которое она занимает. Для ОС типа Windows размер страницы составляет 1024 байта.
Подготовка скрипта создания физической базы данных
Рассмотрим решение этой задачи на учебном примере, который мы использовали в предыдущих лекциях.CREATE TABLE DEPARTAMENT ( DEPNO integer NOT NULL, DNAME char(20), LOC char(20), MANAGER char(20), PHONE char(15), PRIMARY KEY (DEPNO) определение первичного ключа );
CREATE TABLE EMPLOYEE ( EMPNO integer NOT NULL, ENAME char(25), LNAME char(10), DEPNO int, SSECNO char(10), JOB char(25), AGE date, HIREDATE date NOT NULL WITH DEFAULT, SAL dec(9,2), COMM dec(9,2), FINE dec(9,2), PRIMARY KEY (EMPNO) );
CREATE TABLE PROJECT ( PROJNO char(8) NOT NULL, PNAME char(25), BUDGET dec(9,2), PRIMARY KEY (PROJNO) ); CREATE TABLE EMP_PRJ ( EMPNO integer NOT NULL, PROJNO char(8) NOT NULL, WORKS number, PRIMARY KEY (EMPNO, PROJNO), FOREING KEY (EMPNO) REFERENCES EMPLOYEE, FOREING KEY (PROJNO) REFERENCES PROJECT );
CREATE VIEW DEPARTAMENT_V AS SELECT DEPNO, DNAME, LOC, MANAGER, PHONE FROM DEPARTAMENT;
CREATE VIEW EMPLOYEE_V AS SELECT EMPNO, ENAME, LNAME, DEPNO, SSECNO, JOB, AGE, HIREDATE, SAL, COMM, FINE FROM EMPLOYEE; CREATE VIEW PROJECT_V AS SELECT PROJNO, PNAME, BUDGET FROM PROJECT;
Кроме этого, проектировщик решил добавить в физическую модель базы данных еще четыре представления:
CREATE VIEW PERSPROJ AS SELECT ENAME, JOB, PNAME FROM EMPLOYEE, PROJECT, EMPL_PROJ WHERE EMPLOYEE.EMPNO= EMPL_PROJ.EMPNO AND EMPL_PROJ.PROJNO=PROJECT.PROJNO;
CREATE VIEW EMPLIST AS SELECT DEPNO, EMPNO, ENAME, JOB FROM EMPLOYEE GROOP BY DEPNO, EMPNO, ENAME, JOB;
CREATE VIEW PERSPROJ AS SELECT ENAME, JOB, PNAME FROM EMPLOYEE, PROJECT WHERE EMPLOYEE.PROJNO=PROJECT.PROJNO;
CREATE VIEW CURPROJ AS SELECT * FROM PROJECT WHERE START_DATE < SYSDATE WITH CHECK OPTION;
CREATE PUBLIC SYNONYM EMP FOR EPMPLOYEE;
CREATE USER Ivan IDENTIFIED BY EXTERNALLY; CREATE USER Peter IDENTIFIED BY EXTERNALLY; CREATE USER Sidorov IDENTIFIED BY 'alsy_';
Проектировщик базы данных определил пользователям следующие привилегии:
GRANT SELECT ON EMPLOYEE, DEPARTAMENT, PROJECT, EMP_PRJ TO Ivan, Peter, Sidorov;
GRANT INSERT,UPDATE ON EMPLOYEE, DEPARTAMENT, PROJECT, EMP_PRJ TO Ivan;
Никаких других проектных решений проектировщик базы данных принимать не стал.
Далее он составил подробный отчет по каждому объекту базы данных, фрагмент отчета для реляционной таблицы DEPARTAMENT (таблица 13.15) и предал полученные результаты руководителю ИТ-проекта.
| Наименование | DNAME | char(20) |
| Размещение | LOC | char(20) |
| Руководитель | MANAGER | char(25) |
| Телефон | PHONE | char(15) |
Литература: [7], [8], [23], [38], [39], [45].
Пример расчета размера базы данных
Рассмотрим базу данных, которая состоит из таблицы CUSTOMER (ПОКУПАТЕЛЬ), таблицы CONTACT (КОНТАКТ), индекса NDX_CONTACT и представления BAD_CUSTOMER. Команды создания базы данных приведены ниже:CREATE TABLE CUSTOMER (CUSTOMER_ID CHAR(5) NOT NULL, CUSTOMER_NAME VARCHAR(25), CUSTOMER_ADDR VARCHAR(50), CUSTOMER_RATING CHAR(10), PRIMARY KEY(CUSTOMER_ID)) PCTFREE 15;
CREATE TABLE CONTACT (CUSTOMER_ID CHAR(5) NOT NULL, CONTACT_NAME VARCHAR(25) NOT NULL, CONTACT_PHONE DECIMAL(10,0), CONTACT_TEXT LONG VARCHAR, PRIMARY KEY (CUSTOMER_ID, CONTACT_NAME) FOREIGN KEY CUSTKEY (CUSTOMER_ID) REFERENCES CUSTOMER ON DELETE RESTRICT) PCTFREE 15;
CREATE UNIQUE CLUSTERED HASHED INDEX NDX_CUSTOMER ON CUSTOMER (CUSTOMER_ID) SIZE 47628;
CREATE UNIQUE INDEX NDX_CONTACT ON CONTACT ON CONTACT (CUSTOMER_ID,CONTACT_NAME) PCTFREE 10;
CREATE VIEW BAD_CUSTOMER AS SELECT CUSTOMER_NAME, CUSTOMER_ADDR FROM CUSTOMER WHERE CUSTOMER_RATING='POOR';
Оценим размер базы данных в предположении, что она создана под управлением СУБД SQLBASE. Ожидаемое число строк в таблице CUSTOMER - порядка 50000, а в таблице CONTACT - 175000. После загрузки базы данных была выполнена оценка средней длины полей, которая приведена в таблице 13.7.
| CUSTOMER | CUSTOMER_ID | 5 | 5 |
| CUSTOMER_NAME | 25 | 10 | |
| CUSTOMER_ADDR | 50 | 30 | |
| CUSTOMER_RATING | 10 | 5 | |
| CONTACT | CUSTOMER_ID | 5 | 5 |
| CONTACT_NAME | 25 | 15 | |
| CONTACT_PHONE | 10 | 10 | |
| CONTACT_TEXT | 500 | 10 |
Оценка размера базы данных:
Data_Length = 5 + 10 + 30 + 5 = 50 Row_Length = 18 + 6 + (2*4) + 50 = 82 Row_Length_with_Stack = (82*100)/85 =97 Rows_per_Page = (1024 - 86)/97 = 9 Nbr_Row_Pages =50000/9 = 5556 Nbr_Hashed_Table_Pages = 5556/0,7 = 7938 Total_Data_Page = 7938
Так как в этой таблице нет колонок типа LONG VARCHAR, то общее число страниц данных этой таблицы будет равно числу страниц хэш-таблицы.
Data_Length = 5 + 15 + (((10 + 2)/2 + 1) + 12 = 39 Row_Length = 18 + (2*4) + 39 = 65 Row_Length_with_Stack = (65*100)/75 = 87 Rows_per_Page = (1024 - 86)/87 = 10 Nbr_Row_Pages =175000/10 = 17500 Nbr_Long_Pages = 17500 * 1 = 175000 Total_Data_Page = 175000 + 17500 = 192500
Key_Length = 5 +15 = 20 Index_Entry_Length = 9 + 2 + 20 = 31 Usable_Index_Page_Size = (1024 - 74)*(100 - 10)/100 = 855 Index_Entry_per_Page = 855/31 = 27 Nbr_Index_Pages = 175000/27 = 6482
Fixed_Overhead = 12*1024 = 12288 байт Variable_Overhead = 1*150 + 2*170 = 490 байт Variable_Overhead_all_Views = 0 Total_View_overhead_in_Pages = (12288 + 490 + 0)/1024 = 13 страниц
Total_Fixed_Overhead_Pages = 2*12 + 1*2 + 602112/1024 = 614 страниц
Размер базы данных = 7938 + 192500 + 6482 + 13 + 614 = 207560 страниц или 203 Мб.
Проверка физической модели реляционной базы данных
Перед созданием физической базы данных проектировщик базы данных должен проверить созданную им модель физической структуры базы данных на полноту и корректность.Полнота в данном случае означает, что следует убедиться в том, что:
Корректность означает, что в процессе денормализации логической модели базы данных при ее преобразовании в физическую с учетом требований по производительности не была потеряна реляционность отношений базы данных на физическом уровне модели.
Заметим, что наших лекциях не нашли своего отражения ряд вопросов проектирования базы данных, а именно - связанных с выбором программно-аппаратной архитектуры (например, трехзвенная архитектура "клиент-сервер"), настройкой производительности, работой с физическим пространством базы данных и т.д. Как правило, эти вопросы, по большей части связанные с конкретной реализацией базы данных, решаются непосредственно администраторами баз данных, а проектировщики редко привлекаются к решению, в том числе и этих задач, на стадии управления изменениями в процессе начального, тестового, опытного этапов эксплуатации базы данных. В наших лекциях мы акцентировали внимание на тех задачах проектировщика базы данных, которые в основном не зависят от учета конкретной программно-аппаратной среды функционирования базы данных.
На этом этапе проектирования базы данных важно завершить документирование модели. Все объекты и их элементы физической модели должны быть описаны и прокомментированы.
В результате должен быть создан подробный отчет по физической модели. В этом случае неоценимую поддержку в работе проектировщика оказывают CASE-средства поддержки процесса проектирования, например, хорошо известный Erwin или PowerDesigner, которые позволяют в автоматическом режиме создавать такие отчеты.
После разработки или генерирования скрипта создания физической базы данных, загрузки в нее реальных или тестовых данных, проектировщик базы данных обязан с помощью средств СУБД получить информацию о параметрах объектов базы данных, чтобы сопоставить ее с предполагаемыми параметрами, и при необходимости выполнить их корректировку (не забывая отразить эти действия в отчете). Основные параметры объектов, которые следовало бы проконтролировать после создания физической базы данных, приведены в таблицах 13.9.- 13.14. Это касается основных объектов - таблиц, индексов, представлений, синонимов, ролей и пользователей.
| Таблица | Имя таблицы | |
| Столбец | Имя столбца | |
| Default | Устанавливает для столбца значение по умолчанию, которое будет использоваться при отсутствии значения в операторе insert | |
| Ограничение_столбца_ref | Содержит ссылку на ограничение другого столбца, которое должно применяться к данному столбцу | |
| Ограничение_столбца | Устанавливает ограничения целостности как часть определения столбца | |
| Тип_данных | Задает тип данных - числовой, символьный, большой объем и т.д. | |
| Ограничение_таблицы | Устанавливает ограничения целостности для все таблицы | |
| Ограничение_таблицы_ref | Содержит ссылку на ограничение другой таблицы, которое должно применяться к данной таблице | |
| Tablespace | Табличное пространство, в которое должна быть помещена таблица | Табличное пространство по умолчанию, назначенное владельцу таблицы |
| Logging/NoLogging | Указывает, должна ли информация об объекте отслеживаться в файле журнала повтора | Logging |
| Petfree | Указывает, сколько процентов свободного пространства должно сохраняться в каждом блоке данных для будущих обновлений строк таблицы | Диапазон 1-99, по умолчанию 10 % |
| Petused | Задает минимальный объем использованного пространства, поддерживаемый в каждом блоке данных таблицы | Диапазон 1-100, по умолчанию 40 % |
| Initrans | Задает начальное количество транзакционных записей, выделяемых в каждом блоке данных таблицы | Диапазон 1-255, по умолчанию 1 (2 для кластера или индекса) |
| Maxtrans | Задает максимальное количество параллельных транзакций, которые могут обновлять блок данных таблицы (не применяется к запросам) | Диапазон 1-255, значение по умолчанию зависит от размера блока данных |
| Конструкция_хранения | Те же параметры, что и для табличного пространства |
| Unigue | Указывает, что значения столбца (столбцов) индекса должны быть уникальны | Nonunigue |
| Bitmap | Указывает, что будет битовым, а не индексом В-дерева (используется для столбцов с низкой кардинальностью) | В-дерево |
| Схема | Указывает имя владельца таблицы | Схема создателя индекса |
| Имя_индекса | Задает имя индекса | |
| Конструкция кластерного индекса | Указывает, что индекс должен быть построен для кластера, и содержит список кластерных атрибутов | |
| Конструкция индекса таблицы | Указывает таблицу, для которой строится индекс, в том числе любые псевдонимы таблицы, список индексных выражений, а также является ли индекс локальным или глобальным (для разделенных индексов) | По умолчанию используется схема создателя индекса, индекс создается как глобальный |
| Список индексных выражений | Определяет либо столбцы, по которым выполняется индексирование, либо список выражений для создания функционального индекса | Для регулярного индекса не более 32 столбцов; для битового индекса не более 30 |
| ASC/DESC | Указывает, в каком порядке будет создаваться индекс - возрастающем или убывающем | По возрастанию |
| Список физических атрибутов | Те же атрибуты, что и для таблицы: pctfree, pctused, initrans, maxtrans, конструкция_хранения | |
| Logging/Nologging | Указывает, будет ли информация об объекте отслеживаться в файле журнала повтора | Logging |
| Online | Указывает, должен ли индекс быть доступен сразу после создания | Online |
| Compute statistics | Указывает, должна ли генерироваться статистика по индексу | |
| Tablespace | Указывает табличное пространство, в котором будет храниться индекс | Табличное пространство по умолчанию, назначенное создателю индекса |
| Compress/Nocompress | Позволяет исключить повторяющиеся ключевые слова | Nocompress |
| Nosort | Указывает, что значения должны вставляться в порядке возрастания, - Oracle не будет сортировать строки при вставке | |
| Reverce | Сохраняет байты индекса в обратном порядке, за исключением идентификатора строки (row ID) - не может использоваться совместно с nosort |
В результате должен быть создан подробный отчет по физической модели. В этом случае неоценимую поддержку в работе проектировщика оказывают CASE-средства поддержки процесса проектирования, например, хорошо известный Erwin или PowerDesigner, которые позволяют в автоматическом режиме создавать такие отчеты.
После разработки или генерирования скрипта создания физической базы данных, загрузки в нее реальных или тестовых данных, проектировщик базы данных обязан с помощью средств СУБД получить информацию о параметрах объектов базы данных, чтобы сопоставить ее с предполагаемыми параметрами, и при необходимости выполнить их корректировку (не забывая отразить эти действия в отчете). Основные параметры объектов, которые следовало бы проконтролировать после создания физической базы данных, приведены в таблицах 13.9.- 13.14. Это касается основных объектов - таблиц, индексов, представлений, синонимов, ролей и пользователей.
| Таблица | Имя таблицы | |
| Столбец | Имя столбца | |
| Default | Устанавливает для столбца значение по умолчанию, которое будет использоваться при отсутствии значения в операторе insert | |
| Ограничение_столбца_ref | Содержит ссылку на ограничение другого столбца, которое должно применяться к данному столбцу | |
| Ограничение_столбца | Устанавливает ограничения целостности как часть определения столбца | |
| Тип_данных | Задает тип данных - числовой, символьный, большой объем и т.д. | |
| Ограничение_таблицы | Устанавливает ограничения целостности для все таблицы | |
| Ограничение_таблицы_ref | Содержит ссылку на ограничение другой таблицы, которое должно применяться к данной таблице | |
| Tablespace | Табличное пространство, в которое должна быть помещена таблица | Табличное пространство по умолчанию, назначенное владельцу таблицы |
| Logging/NoLogging | Указывает, должна ли информация об объекте отслеживаться в файле журнала повтора | Logging |
| Petfree | Указывает, сколько процентов свободного пространства должно сохраняться в каждом блоке данных для будущих обновлений строк таблицы | Диапазон 1-99, по умолчанию 10 % |
| Petused | Задает минимальный объем использованного пространства, поддерживаемый в каждом блоке данных таблицы | Диапазон 1-100, по умолчанию 40 % |
| Initrans | Задает начальное количество транзакционных записей, выделяемых в каждом блоке данных таблицы | Диапазон 1-255, по умолчанию 1 (2 для кластера или индекса) |
| Maxtrans | Задает максимальное количество параллельных транзакций, которые могут обновлять блок данных таблицы (не применяется к запросам) | Диапазон 1-255, значение по умолчанию зависит от размера блока данных |
| Конструкция_хранения | Те же параметры, что и для табличного пространства |
| Unigue | Указывает, что значения столбца (столбцов) индекса должны быть уникальны | Nonunigue |
| Bitmap | Указывает, что будет битовым, а не индексом В-дерева (используется для столбцов с низкой кардинальностью) | В-дерево |
| Схема | Указывает имя владельца таблицы | Схема создателя индекса |
| Имя_индекса | Задает имя индекса | |
| Конструкция кластерного индекса | Указывает, что индекс должен быть построен для кластера, и содержит список кластерных атрибутов | |
| Конструкция индекса таблицы | Указывает таблицу, для которой строится индекс, в том числе любые псевдонимы таблицы, список индексных выражений, а также является ли индекс локальным или глобальным (для разделенных индексов) | По умолчанию используется схема создателя индекса, индекс создается как глобальный |
| Список индексных выражений | Определяет либо столбцы, по которым выполняется индексирование, либо список выражений для создания функционального индекса | Для регулярного индекса не более 32 столбцов; для битового индекса не более 30 |
| ASC/DESC | Указывает, в каком порядке будет создаваться индекс - возрастающем или убывающем | По возрастанию |
| Список физических атрибутов | Те же атрибуты, что и для таблицы: pctfree, pctused, initrans, maxtrans, конструкция_хранения | |
| Logging/Nologging | Указывает, будет ли информация об объекте отслеживаться в файле журнала повтора | Logging |
| Online | Указывает, должен ли индекс быть доступен сразу после создания | Online |
| Compute statistics | Указывает, должна ли генерироваться статистика по индексу | |
| Tablespace | Указывает табличное пространство, в котором будет храниться индекс | Табличное пространство по умолчанию, назначенное создателю индекса |
| Compress/Nocompress | Позволяет исключить повторяющиеся ключевые слова | Nocompress |
| Nosort | Указывает, что значения должны вставляться в порядке возрастания, - Oracle не будет сортировать строки при вставке | |
| Reverce | Сохраняет байты индекса в обратном порядке, за исключением идентификатора строки (row ID) - не может использоваться совместно с nosort |
Создание пользователей
Одной из задач, которая чаще всего решается в процессе эксплуатации базы данных, является создание пользователей базы данных. В контексте баз данных термин "пользователь" имеет два основных значения:На самом деле под созданием пользователя базы данных понимают создание учетной записи пользователя (user account) в словаре данных, с помощью которой пользователь может войти в базу данных для выполнения своей работы. Учетные записи представляют собой способ организации доступа пользователя к базе данных, выдачи разрешений на выполнение требуемых задач, а также отслеживания выполняемых пользователем действий. Такая учетная запись включает имя пользователя базы данных, которое присваивают пользователю в базе данных, пароль, указание которого разрешает доступ к объектам базы данных, уровень полномочий или уровень доступа и еще ряд опциональных параметров. Уровень доступа означает тип операций, которые данный пользователь может выполнять (создавать таблицу, определять пользователей и т.д).
Пользователь является объектом базы данных. При создании пользователя базы данных обязательным является указание имени. Остальные параметры могут быть установлены администратором базы данных позже с помощью команды SQL ALTER USER.
Создание пользователей называется еще задачей авторизации или аутентификации пользователей. Решение этой задачи возлагается на администраторов базы данных. Проектировщик во время проектирования базы данных, совместно с администратором базы данных, может создать всех потенциальных пользователей. Хорошим тоном проектирования является создание проектировщиком следующих пользователей: разработчиков приложения базы данных и тестировщиков базы данных. Именно эти лица получают спроектированную базу данных в опытную эксплуатацию.
Чтобы создать пользователей базы данных, проектировщик должен иметь список лиц, которым будут разрешен доступ к базе данных.
Для создания пользователей базы данных или учетной записи пользователя используется команда SQL CREATE USER, неполный синтаксис которой приведен ниже:
CREATE USER имя_пользователя IDENTIFIED BY [пароль|EXTERNALLY];
Ключевое слов EXTERNALLY указывает, что должна быть использована аутентификация операционной системы.
Для исключения пользователей из базы данных применяется команда DROP USER.
В качестве примера создадим пользователей нашей учебной базы данных. Допустим, что у нас есть следующий фрагмент списка лиц, которые в организации будут пользоваться базой данных:
... Иванов А.А. - разработчик приложения Петров В.В. - разработчик приложения Сидоров С.С. - тестировщик базы данных …
Иванов и Петров уже имеют системную аутентификацию, и администратор базы данных решил, что учетная запись для их доступа к базе данных будет такой же. Их имена для входа в систему - Ivan и Peter, соответственно. Сидоров - это новый сотрудник, который будет принят на работу через 1,5 месяца специально для тестирования базы данных. Совместно с администратором базы данных было решено, что его имя для входа в базу данных будет Sidorov, а пароль - alsy_. Тогда проектировщик базы данных может включить в свой скрипт следующие команды:
CREATE USER Ivan IDENTIFIED BY EXTERNALLY; CREATE USER Peter IDENTIFIED BY EXTERNALLY; CREATE USER Sidorov IDENTIFIED BY 'alsy_';
Создание табличных пространств
Проектировщик базы данных работает с логическими объектами - табличными пространствами, таблицами, представлениями, индексами и т.д., так называемыми логическими файлами СУБД Oracle. Информация о содержимом логических файлов хранится в словаре данных.Одним из самых трудных для понимания и объяснения объектов реляционной базы данных Oracle является табличное пространство (tablespace). Табличным пространством в Oracle называется логическая область хранения данных, размер которой ограничен размером используемого жесткого диска. Физические файлы создаются на уровне табличного пространства.
Выделением места для табличных пространств и способом их совместного использования управляют администраторы базы данных. Поэтому проектировщики базы данных должны при использовании табличных пространств работать в тесном сотрудничестве с ними.
Табличные пространства можно создавать, менять и удалять. Для создания табличных пространств в СУБД Oracle предусмотрена команда SQL CREATE TABLESPACE, параметры которой приведены в таблице 13.8.
| Имя_табличного_пространства | Имя, присваемое табличному пространству. Оно должно отражать назначение этого табличного пространства | |
| Спецификация файла данных | ||
| Местонахождение файла | Полный путь к каталогу и имя файла | |
| size | Полный начальный размер файла данных, в соответствии с которым выделяется дисковое пространство | |
| reuse | Если файл данных существует, его нужно использовать повторно, указав этот параметр, в противном случае возникнет ошибка. Размер файла должен совпадать с указанным в параметре size | |
| autoextend | Разрешает или запрещает автоматическое увеличение размера файла данных.Может принимать значения on и off. Для on существуют дополнительные параметры: next: величина приращения файла (в байтах). maxsize: наибольший допустимый размер файла данных. Может быть неограниченным (unlimited) | ON |
| minimum extend | Предназначен для управления фрагментацией - определяет минимальный размер экстента | |
| default предложение хранения | объем пространства, выделяемого объекту при отсутствии явно указанной конструкции хранения | |
| initial | Объем пространства, выделяемого для первого экстента страниц | 5 |
| next | Объем для пространства, выделяемого для второго и последующих экстентов | 5 физических страниц |
| minextens | Минимальное количество выделяемых экстентов | 1 |
| maxextents | Максимальное количество выделяемых экстентов - может быть неограниченным (intimated) | 121 |
| petincrease | Коэффициент приращения размера (в %) для каждого следующегоэкстента после next | 50 |
| freelist groops | Используется в режиме параллельного сервера и указывает количество списков свободных блоков для объектов, созданных в данном табличном пространстве без использования конструкций хранения | |
| freelist | Указывает количество списков свободных блоков, созданных в данном табличном пространстве без использования конструкций хранения | |
| optimal | Применяется только к сегментам отката и определяет минимальный объем пространства, до которого сокращается сегмент отката после расширения за пределы оптимального значения | |
| online/offline | Указывает, режим (оперативный/автономный, в котором изначально должно находиться табличное пространство | online |
| permanent/temporary | Указывает, будет ли табличное пространство содержать объекты или только временные сегменты | permanent |
| Предложение управления экстентами | ||
| dictionary | Указывает, что управление экстентами осуществляется только через словарь данных | dictionary |
| local | Указывает, что некоторая часть табличного пространства зарезервирована для битовых карт | user |
| plugged_in | Используется с переносимыми табличными пространствами и указывает, что табличное пространство может быть "подключено" к базе данных | NO |
В качестве примера создадим табличное пространство, не используя никаких параметров, как показано ниже.
CREATE TABLESPACE my_ts DATAFILE 'c:\ora9i\oradata\orcr\myfile01.dbf' SIZE 2M;
Ключевое слово TABLESPACE задает имя табличной области (my_ts), ключевое слово DATAFILE задает спецификацию файла операционной системы ('c:\ora9i\oradata\orcr\myfile01.dbf'), в котором будут размещаться данные создаваемой табличной области, ключевое слово SIZE задает размер табличного пространства в мегабайтах. Остальные значения параметров принимаются по умолчанию. В частности, поскольку значение по умолчанию для параметра AUTOEXTEND есть ON (см. таблицу 13.8), то разрешено автоматическое расширение пространства, выделенного для данного табличного пространства. По умолчанию созданное табличное пространство переходит в оперативный режим (ONLINE) и является постоянным табличным пространством (PERMANENT).
Для изменения параметров табличного пространства используется команда ALTER TABLESPACE, а для удаления - команда DROP.
Чтобы разместить объект базы данных в определенном табличном пространстве, необходимо явно указать это табличное пространство в командах SQL. Например, команда
CREATE TABLE CUSTOMER (CUSTOMER_ID CHAR(5) NOT NULL, CUSTOMER_NAME VARCHAR(25), CUSTOMER_ADDR VARCHAR(50), CUSTOMER_RATING CHAR(10)) TABLESPASE my_st, PCTFREE 15;
размещает таблицу CUSTOMER и табличном пространстве my_st.
Средства разграничения доступа в СУБД Oracle
Современный уровень развития средств вычислительной техники характеризуется высокой степенью распределенной обработки данных, когда логически единая информационная база данных размещается в сетевой среде. Вычислительные сети характеризуются объединением различных компьютеров на основе программно-аппаратной платформы, асинхронной многопользовательской обработкой и развитыми средствами разграничения доступа. При этом реальная сложность организации управления доступа скрыта от пользователя. Логическое пространство базы данных должно выглядеть для пользователя так, как если бы вся база данных располагалась на его локальном компьютере.При работе с базой данных должна быть обеспечена высокая степень безопасности данных практически без усложнения работы пользователя. Одной из неотъемлемых функций любой промышленной СУБД, в том числе и Oracle, является обеспечение защиты информации на уровне доступа к данным. Для этого в СУБД Oracle используется система избирательного управления доступом. Это означает, что администратор базы данных создает пользователей и управляет их полномочиями на выполнение конкретных операций с конкретными объектами в базе данных.
Задача распознавания пользователей и разграничения доступа между различными пользователями базы данных решается как на уровне средств операционной системы, так и на уровне СУБД. Стандартным подходом к решению этой задачи на обоих уровнях является поддержка механизма создания (регистрации) пользователя и назначения ему привилегий. С другой стороны, каждый пользователь, создающий некоторый объект, должен иметь право на управление доступом к этому объекту. Типичное решение состоит в реализации концепции привилегий или прав доступа. Привилегия - это некоторый поддерживаемый СУБД или операционной системой признак, который определяет, может ли конкретный пользователь выполнить конкретную операцию.
Для этого администраторы базы данных создают пользователей базы данных и предоставляют им некоторые полномочия по доступу к объектам базы данных.
Обеспечение правомерности доступа пользователя реализуется средствами аутентификации системы, простейшим из которых является использование пароля, подтверждающего подлинность пользователя. Для входа в базу данных пользователь должен ввести имя и подтвердить свою подлинность паролем.
В СУБД Oracle реализована поддержка принципа безопасности по умолчанию, который состоит в назначении наименьших привилегий. Т.е. пользователь может получить доступ к объекту базы данных или выполнить определенные действия в базе данных, только если ему это явно разрешено.
Концепция обеспечения безопасности доступа, принятая в Oracle, предусматривает выполнение следующих действий:
Проектировщик базы данных решает эти задачи, исходя из предположения, что база данных доступна. В терминах СУБД Oracle это означает, что администратор базы данных запустил экземпляр (instance) сервера базы данных.
Основы проектирования реляционных баз данных
Анализ функциональной модели предметной области базы данных
Чтобы спроектировать модули приложений, необходимо знать, как будет работать информационная система с базой данных. Такую информацию можно получить из функциональной модели предметной области базы данных. Для проектирования модулей приложений проектировщику базы данных нужен набор спецификаций функций, которые задают необходимые требования к обработке бизнес-данных, а также набор зависимостей между различными бизнес-функциями.Фактически это означает, что входом для решения задачи проектирования модулей приложений базы данных является иерархия функций. На выходе проектировщик должен получить описание (спецификацию) модулей приложений, а в процессе проектирования модулей проектировщик строит отображение бизнес-требований в спецификации модулей.
Алгоритм действий проектировщика базы данных состоит в следующем: сначала проектировщик пытается сформулировать бизнес-требования (функции) в самом общем виде, а затем выполняет декомпозицию каждой такой бизнес-функции до тех пор, пока не будет получена некоторая функция, которую можно считать атомарной функцией. Критерием атомарности функции является получение ответа на вопрос, имеет ли смысл выполнить только часть функции.
Пример. Рассмотрим фрагмент иерархии функций для обработки заявлений о выплате страхового возмещения. На упрощенной схеме рис. 14.1 показана функция "2. Обработать заявление". Выполнение этой функции включает выполнение четырех функций следующего уровня: "2.1. Зарегистрировать заявление", "2.2. Принять решение по заявлению", "2.3. Произвести платеж по заявлению", "2.4. Закрыть заявление".
На рис. 14.1 показана дальнейшая декомпозиция функции "2.2. Принять решение по заявлению". Полученная на этом этапе функция "2.2.5. Разрешить ремонт" является атомарной функцией. Ремонт разрешается либо не разрешается.
Рис. 14.1. Иерархия функции для обработки заявлений о выплате страхового возмещения
При рассмотрении иерархии функций проектировщику базы данных следует обратить внимание на следующие моменты:
Общие принципы разработки спецификаций модулей
После разработки схемы "функции-модули" и схемы "модули-данные" проектировщик приступает к решению довольно трудоемкой задачи - написанию спецификаций модулей. Именно это спецификация позволит программистам и компоновщикам построить реальную систему с использованием базы данных.При написании спецификаций следует исходить из того, что человек, который будет писать код, умеет это делать. Поэтому из спецификаций нужно по возможности исключить все указания по тому, как нужно, с вашей точки зрения, писать код. Это следует из того практического соображения, что никто не может создать правильный код без его тестирования. Поскольку проектировщик базы данных, как правило, сам не собирается писать код, то ему в спецификации не следует диктовать структуру реального кода.
Алгоритмы, даже очень сложные, следует формулировать в общем виде. Нужно стараться избегать формальных языков описания алгоритмов.
Также не следует вставлять в спецификации модулей команды SQL. В процессе тестирования администратор базы данных может изменить разработанную проектировщиком базы данных физическую модель базы данных, и, следовательно, команды могут измениться.
Следует избегать лишних инструкций в спецификациях. Например, не нужно объяснять программистам, что они должны выйти из цикла при исключительных ситуациях.
Спецификация модуля должна обязательно включать следующее:
Пример. Приведем типовую спецификацию модуля для предоставления пользователю доступа к приложению базы данных.
Наименование модуля: Страница для входа в приложение (LogIn).
Цель: идентификация пользователя и предоставление доступа к приложению базы данных.
Входные данные
Имя пользователя
Пароль
Таблица базы данных: USERACCOUNT
Колонки:
USERNAME - запрашивается, используется в предикате поиска
USERPASS - запрашивается, используется в предикате поиска
Действия:
Если пользователя с таким именем и паролем нет в базе данных - отказать в доступе и попросить правильно ввести свои данные (на случай ошибки), но не более трех раз.
Если пользователь есть в базе данных - предоставить доступ к модулю "Главная страница", которая в зависимости от полномочий пользователя может иметь различный внешний вид.
Комментарий:
В зависимости от типа модуля (экранная форма, отчет и т.д.), спецификации могут включать дополнительную информацию, такую как требования к расположению кнопок или формат отчета. Для таких модулей спецификацию следует дополнить следующими позициями:
Пример. В качестве примера приведем спецификацию экранной формы для работы с базой данных через браузер.
Наименование экранной формы: Web-страница Форма 3: Список исполнителей.
Цель: приписать исполнителей к проекту, определить их занятость и статус.
Входные данные
Навигация:
Вызывается из модуля "Редактирование Формы 1".
Возвращает управление в модуль "Редактирование Формы 1".
Действия:
Таблицы:
| ENPID | Внутренний номер служащего | INSERT |
| PROJID | Внутренний номер проекта | INSERT |
| TN | табельный номер (из представления) | |
| NM | ФИО | INSERT |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | Ученое знание | |
| JOB | Занятость в проекте в мес. | INSERT |
| EMPSTATUS | Статус исполнителя | INSERT |
| ENPID | Внутренний номер служащего | |
| TN | табельный номер (из представления) | |
| NM | ФИО | Предикат поиска |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | ученое звание |
Входные данные
Имя пользователя
Пароль
Таблица базы данных: USERACCOUNT
Колонки:
USERNAME - запрашивается, используется в предикате поиска
USERPASS - запрашивается, используется в предикате поиска
Действия:
Если пользователя с таким именем и паролем нет в базе данных - отказать в доступе и попросить правильно ввести свои данные (на случай ошибки), но не более трех раз.
Если пользователь есть в базе данных - предоставить доступ к модулю "Главная страница", которая в зависимости от полномочий пользователя может иметь различный внешний вид.
Комментарий:
В зависимости от типа модуля (экранная форма, отчет и т.д.), спецификации могут включать дополнительную информацию, такую как требования к расположению кнопок или формат отчета. Для таких модулей спецификацию следует дополнить следующими позициями:
Пример. В качестве примера приведем спецификацию экранной формы для работы с базой данных через браузер.
Наименование экранной формы: Web-страница Форма 3: Список исполнителей.
Цель: приписать исполнителей к проекту, определить их занятость и статус.
Входные данные
Навигация:
Вызывается из модуля "Редактирование Формы 1".
Возвращает управление в модуль "Редактирование Формы 1".
Действия:
Таблицы:
| ENPID | Внутренний номер служащего | INSERT |
| PROJID | Внутренний номер проекта | INSERT |
| TN | табельный номер (из представления) | |
| NM | ФИО | INSERT |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | Ученое знание | |
| JOB | Занятость в проекте в мес. | INSERT |
| EMPSTATUS | Статус исполнителя | INSERT |
| ENPID | Внутренний номер служащего | |
| TN | табельный номер (из представления) | |
| NM | ФИО | Предикат поиска |
| PS | Должность | |
| GR | Разряд | |
| DR | Ученая степень | |
| ZV | ученое звание |
Определение функций
При разработке иерархии функций аналитик должен предоставить текстовое описание к каждой функции, по крайней мере для верхнего и самого нижнего уровней иерархии. Желательно, чтобы в этом описании аналитики выделяли сущности предметной области. Это важно для того, чтобы знать с какими сущностями предметной области работает функция, т.е. какие потенциальные объекты реляционной базы данных будут использоваться в каждой функции. Если это не сделано, то проектировщику базы данных придется делать это самостоятельно.Пример. Определения функции "2.2.2. Проверить обеспечено ли заявление".
"Получить и зарегистрировать все требуемые страховой компанией сведения о заявлении (СВЕДЕНИЯ О ЗАЯВЛЕНИИ), включая все подробные сведения о третьих сторонах (СТОРОННИЕ ЮРИДИЧЕСКИЕ ЛИЦА) и свидетелях (ФИЗИЧЕСКИЕ ЛИЦА).
Изучить страховой полис (ПОЛИС) на предмет наличия исключительных ситуаций (ИСКЛЮЧЕНИЯ) и определить, действуют ли эти ситуации в случае данного заявления (ЗАЯВЛЕНИЕ).
Если имеется исключение, то закрыть заявление и составить стандартное письмо заявителю об отказе в выплате (ПИСЬМО) заявителю (ЗАЯВИТЕЛЬ).
Если никаких исключений нет, то изменить статус заявления на ожидание оценки, назначить и уведомить оценщика (ОЦЕНЩИК)."
Из примера видно, какие сущности предметной области участвуют в выполнении функции (выделены в скобках), как меняется состояние сущности (выделено курсивом) и каков алгоритм работы этой функции.
Из примера ясно, что на этом этапе проектировщик базы данных в качестве входных данных использует также информационную модель предметной области базы данных (описание сущностей).
При выполнении анализа функций полезно иметь некоторую таблицу (матрицу) "Функция-Сущность". Эта матрица должна дать ответ на следующие вопросы:
Процесс анализа взаимодействия функции и сущности принято обозначать аббревиатурой CRUD (Create, Reference, Update, Delete - создание, ссылка, модификация, удаление).
Полезными для понимания проектировщиком базы данных назначения функций и того, как данные функции участвуют в процессе обработки данных в системе, могут быть диаграммы потока данных и диаграммы жизненных циклов сущностей, которые были рассмотрены нами во второй лекции. Последние, в частности, дают ясную картину изменения состояния сущности, что важно в определении атрибутов статуса сущности.
Отображение функций в модули
Одной из основных задач проектирования модулей приложений является построение отображения функций в модули. При решении этой задачи проектировщик базы данных должен акцентировать внимание на структуре базы данных, которая составляет основу приложения.Как правило, решение задачи отображения функций в модули решается в четыре этапа:
Из предложенного выше подхода видно, как тесно переплетаются в процессе проектирования процессы разработки физической модели базы данных и спецификаций модулей приложений. Таким образом, если проектировщиком был разработан черновой вариант физической модели базы данных по алгоритмам, рассмотренным нами в предыдущих лекциях, то на этом этапе он должен быть адаптирован к реализации функций и, возможно, значительно переработан.
К сожалению, никаких унифицированных и простых способов отображения функций в модули приложений не существует. Это обусловлено двумя обстоятельствами: комбинаторной сложностью построения отображений множеств (теоретически доказано, что для такого класса комбинаторных задач не существует в общем случае алгоритмов с линейной сходимостью) и сложностью выработки критерия того, что полученное отображение оптимально (т.е. довольно широкий семантический произвол в обосновании вариантов того или иного отображения). Как показывает опыт проектирования, мнение относительно состава и количества модулей приложений в процессе проектирования меняется неоднократно.
В последнее время хорошие результаты в разработке и проектировании систем и, в частности, модулей приложений получены с применением объектно-ориентированного подхода на основе унифицированного языка моделирования UML и CASE-инструментария, который этот язык поддерживает. Однако рассмотрение этой методики разработки систем представляет собой предмет отдельного курса, и здесь излагаться не будет. В списке литературы к лекции указаны монографии и учебники по этой популярной методике.
Однако рассмотрение этой методики разработки систем представляет собой предмет отдельного курса, и здесь излагаться не будет. В списке литературы к лекции указаны монографии и учебники по этой популярной методике.
При отображении функций в модули необходимо получить схему, которая ставит в соответствие каждой функции определенный модуль.
Пример. Рассмотрим нашу учебную базу данных, содержащую информацию о сотрудниках, отделах и проектах организации. Допустим, она будет поддерживать бизнес-функцию "Управление проектами в организации". Функциональная модель предметной области базы данных в терминах иерархии функций приведена на рис. 14.2, а на рис. 14.3 приведен перечень функций управления проектами в организации.
Рис. 14.2. Иерархия бизнес-функции "Управление проектами в организации"
Рис. 14.3. Перечень функции управления проектами в организации
Задача состоит в отображении функций из перечня на рис. 14.3 в список модулей.
Сначала из перечня функций должны быть удалены те функции, которые не будут поддерживаться приложением базы данных. Проектировщик узнает у руководителя проекта, что в приложении базы данных не будут поддерживаться следующие функции:
Таким образом, будет получен список функций, который показан в левой колонке таблицы 14.1. Этому списку функций должен быть поставлен в соответствие список модулей приложения базы данных.
| Назначить руководителяя проекта | Ввод информации о проекте | |
| Определить бюджет проекта | Ввод информации о сотрудниках | |
| Определить список подразделений | Поиск информации о сотрудниках | |
| Определить список сотрудников | Поиск информации о проектах | |
| Выполнять проект | Генерация отчета о выполненных проектах | |
| Сдать проект | Генерация отчета о выполняемых проектах |
Руководитель проекта передал проектировщику базы данных характеристику приложения базы данных по управлению выполнением проектов в организации. Это приложение будет заниматься учетом выполняемых и выполненных проектов в организации. Главными вопросами, на которые должно отвечать приложение, являются:
Проектировщик базы данных составил список модулей приложения базы данных (правая колонка таблицы 14.1) и установил отображение функций в модули, как показано на рис. 14.4.
Рис. 14.4. Отображение функции в модули
Приведенный пример показывает общий принцип построения отображения бизнес-функций в модули.
В дополнение будет весьма полезным к разработанной схеме "функции-модули" составить схему "модули-данные", опираясь на изучение определения функций.
При составлении схемы "модули-данные" используется описание функций, логическая модель данных или итерация физической модели данных.
Пример. Рассмотрим модуль "Ввод информации о сотрудниках" из предыдущего примера и составим для него схему "модули-данные". При этом мы используем схему базы данных, приведенную на рис. 14.5.
Рис. 14.5. Физическая модель базы данных
Один из возможных результатов, который может быть получен проектировщиком базы данных, приведен в таблице 14.2.
| Ввод информации о сотрудниках | Employee | Empno | Чтение |
| Ename | Чтение, Поиск | ||
| Lname | Чтение, Поиск | ||
| Job | Чтение | ||
| Sal | Чтение | ||
| Depno | Чтение, Поиск | ||
| Department | Depno | Чтение, Поиск | |
| Manager | Чтение | ||
Проектирование процесса тестирования модулей приложений
Тестирование приложения базы данных есть один из основных элементов подготовки и проведения приемо-сдаточных испытаний. Как показывает практика, планирование тестирования приложений базы данных должно начинаться еще на стадии анализа. Имеется вероятность того, что заказчик может отказаться от ранее принятых критериев испытаний в процессе выполнения проекта. Однако чаще всего планирование тестирования откладывают до этапа проектирования, и, таким образом, составление плана тестирования становится задачей проектировщика базы данных или администратора баз данных.процессе тестирования должно быть выяснено, что приложение базы данных делает то, что от него требуется, т.е. отвечает сформулированным требованиям приемо-сдаточных испытаний.
Как правило, в процессе проектирования проектировщик базы данных предлагает стратегию (или план) комплексного и системного тестирования. При разработке стратегии тестирования следует помнить о том, что должны использоваться тесты следующих категорий:
Обычно после проведения приемо-сдаточных испытаний подписывается Акт приемки-сдачи. Считается, что система переходит в состояние опытной эксплуатации, на которой выявляются и исправляются ошибки. После окончания стадии опытной эксплуатации система переходит в состояние промышленной эксплуатации, т.е. становится производственным ресурсом компании.
Как правило, тесты и их проведение планируются для удовлетворения требований приемо-сдаточных испытаний. Поэтому разработку стратегии тестирования следует начинать с детального изучения этих требований.
Планирование тестирования приложений базы данных зависит от используемых внутри организации стандартов и методик разработки информационных систем с базами данных. Такие методики различаются как по своему подходу к разработке систем, так и по составу производимой проектной документации.
Так, например, методики разработки, предлагаемые компаниями Microsoft и IBM, отличаются по составу проектной документации, хотя во многом схожи по методологической основе (объектно-ориентированному подходу).
Рассмотрим подход, который основан на модели проектной группы Модель MSF версии 3.1, предлагаемой компанией Microsoft. В этой методике предусмотрен так называемый ролевой кластер "Тестирование".
Задача ролевого кластера "Тестирование" (test) - одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Обнаружение и устранение дефектов может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта. Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом - как для проектной команды, так и для заказчика.
Чтобы достичь успеха, команда тестировщиков должна фокусироваться на определенных ключевых задачах. Они структурируются в виде трех областей компетенции.
Планирование тестов. Данная область компетенции (планирование тестов - test planning) ролевого кластера "Тестирование" формулирует методологию нахождения и урегулирования проблем качества продукта.
Команда тестировщиков разрабатывает планы и методики тестирования и таким образом формирует стратегию, используемую в проекте для тестирования решения.
В заключение раздела рассмотрим некоторые практические рекомендации проектировщикам базы данных при разработки стратегии тестирования.
Стратегия тестирования - это план проведения работ по тестированию системы или ее модуля, учитывающий специфику функциональности и взаимозависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования и может задавать описания или требования к необходимым для проведения тестирования инструментам и инфраструктуре.
Стратегия тестирования должна отвечать на следующие вопросы:
В качестве дополнительной задачи, которая решается в процессе понимания стратегии тестирования, можно рассматривать задачу минимизации затрат на тестирование.
Из стратегии тестирования органично выписывается план тестирования. Шаблоны планов тестирования, предлагаемые различными методологиями, зачастую прямо включают одним из разделов описание стратегии тестирования или же включают описание стратегии в пункты плана, отвечающие за тестирование конкретных частей функционала. К примеру, шаблон методологии Rational Unified Process определяет стратегию тестирования как самый большой раздел плана тестирования.
Заказчик зачастую хочет контролировать процесс тестирования и видеть понимание задачи тестирования исполнителями по проекту. Для него стратегия тестирования - это менее детальный документ-видение того, как будет тестироваться система в процессе разработки.
При разработке стратегии тестирования для распределенной системы с базой данных проектировщику базы данных нужно выделить основные области, которые могут тестироваться отдельно друг от друга.
Объединим в рамках рассматриваемого примера тестирование функциональности сервера приложений и базы данных. Пусть сервер приложения реализует 20 команд по обработке данных и пользовательских сессий (без учета работы с системными пулами соединений, функций сжатия передаваемого по сети трафика и т.п.). Сервер баз данных реализует 10 системных операций по архивации данных, построению статистики использования отчетов и еще несколько подобных операций. Общий смысл заключается в том, что мы имеем конечный набор тестируемых операций, и так как конфигурации определены заранее, можем говорить о конечном наборе тестов, которые необходимо выполнить, чтобы проверить работоспособность серверного функционала системы. Итог - 30 тестов на серверной стороне. Заметим, что в данном примере мы не затрагиваем нагрузочную составляющую тестирования: речь идет только о функциональном тестировании.
При разработке стратегии тестирования проектировщик базы данных должен учитывать, что, планируя тестирование, он не начинает разбираться с системой, а занимается непосредственно планированием, выделением ресурсов и сроков на конкретные задачи.
Тестирование информационных систем является бурно развивающейся прикладной наукой. Практика показывает целесообразность применения CASE-средств для организации и проведения тестирования. В списке литературы к лекции указаны источники, которые следует использовать для углубленного изучения разработки планов тестирования приложений базы данных.
В этой лекции мы закончили обсуждение основных задач проектировщика базы данных, которые он должен выполнить обязательно (построение логической, физической модели данных, подготовка скрипта для создания базы данных и документирование модели), и в решении которых его участие очень желательно (планирование модулей приложений, планирование тестирования).
В двух последних лекциях мы рассмотрим задачи управления изменениями в структуре базы данных (или задачи обратного влияния), которые могут потребовать непосредственного участия проектировщика базы данных.
Литература: [9], [17], [18], [19], [22], [30], [33], [45].
Размещение логики обработки
Сложность решения задачи проектирования модулей обусловлена еще и тем, что проектировщик баз данных должен выделить из всего планируемого кода серверный код, создание которого обсуждалось в одной из предыдущих лекций. При этом следует придерживаться следующих простых правил:В настоящем разделе мы рассмотрим некоторые факторы, которые должны учитывать проектировщики баз данных при разграничении управления пользовательским интерфейсом приложений и выполнением операций обработки данных в модулях.
Как отмечают специалисты в области разработки и проектирования информационных систем, многие недостатки в прикладных системах вызваны тем, что в них не определены различия между правилами для данных, правилами для процессов и правилами для интерфейса. Рассмотрим основные.
Правила для данных. В правилах для данных формулируются условия, которым должны удовлетворять данные. Эти правила действуют для каждого экземпляра данных и выводятся из модели данных.
Примерами правил для данных являются следующие:
Правила для процессов. В правилах для процессов определяется, что может (и что не может) делать приложение. Эти правила обычно выводятся из модели функций.
Примерами правил для процессов являются следующие:
Это правило следует реализовать в приложении, в нем ничего не говорится о содержимом и определении базы данных. Оно выражает утверждение о том, что может быть, а чего не может быть.
Правила для интерфейса. В правилах для интерфейса устанавливается, каким должен видеть пользователь приложение. Эти правила не касаются обработки, а только влияют на представление пользователя о приложении базы данных. Эти правила выводятся из спецификации пользовательского интерфейса.
Примерами правил для интерфейса являются следующие:
Некоторые сформулированные правила бывают составными, а их составные части относятся к разным группам правил. Например, рассмотрим правило:
Все торговые операции, производимые в воскресенье, учитываются в бухгалтерских книгах за следующий понедельник.
Это два правила. Первое утверждает, что проводки по торговым операциям в бухгалтерских книгах нельзя делать за воскресенье. Это правило для данных. Второе разъясняет приложению, как откорректировать дату проводки, чтобы она стала приемлемой. К дате проводки, выпадающей на понедельник, нужно добавить единицу. Это правило для процессов.
Выделение и анализ этих трех групп правил приводит к формированию трех наборов документов: описание структуры интерфейса, структура процессов, которая определяет, как должен быть реализован интерфейс, и структура данных, задающая основные объекты базы данных, с которыми работают процессы.
Эти документы играют важную роль как в определении и логике, и ее размещении в приложении, так и в составлении спецификации модулей приложений базы данных.
Остановимся кратко на основных принципах размещения бизнес-логики в модулях приложения базы данных.
Правила для интерфейса реализуются во внешней (клиентской) части системы, независимо от того, какие языки программирования или генераторы отчетов используются. Правила для процессов реализуются в виде процедур, вызываемых из клиентской части системы. Они могут представлять серверный код, либо быть реализованы в виде модулей или библиотек на сервере приложений. Правила для данных реализуются самой базой данных в виде ограничений или триггеров.
Системные модули
Как указывалось выше, целью проектирования модулей является реализация функциональных возможностей, которые удовлетворяют бизнес-требованиям, выявленным в функциональной модели предметной области базы данных. Однако при этом необходимо рассмотреть достаточное число процессов, которые не вытекают непосредственно из сформулированных бизнес-функций. Например, возможность выдачи результатов работы модуля в файл или на принтер.Набор модулей приложений базы данных, который непосредственно не следует из бизнес-функций, но необходим для обеспечения работы системы, называется системным.
К таким модулям можно отнести процедуры резервного копирования и автоматического восстановления, модули, предоставляющие пользователям возможность менять свой пароль, модули печати, модули навигации по приложениям базы данных и т.д.
Проектировщик базы данных самостоятельно разрабатывает спецификации таких модулей.
Основы проектирования реляционных баз данных
Декларативные языки обработки данных
С началом использования SQL-технологии и систем реляционных БД стало возможным разрушить взаимосвязь между прикладными программами и физическими структурами данных. Декларативные языки обработки данных только специфицируют, какие данные необходимы прикладной программе, оставляя за СУБД привилегию определять, как осуществлять навигацию по физической структуре данных для доступа к требуемым данным. SQL есть пример декларативного языка обработки данных.Концепция независимости прикладных программ от физической структуры данных дает несколько значительных преимуществ.
Дерево запроса
Одним из способов представления запроса, которое обеспечивает понимание механизма его выполнения, является дерево запроса (query tree). Дерево запроса представляет собой древовидную структуру, в которой окончательный результат запроса находится на вершине дерева (в его корне) и таблицы БД, участвующие в запросе, являются листьями этого дерева. Промежуточные узлы дерева представляют физические операции, которые должны выполняться во время запроса. Когда план запроса выполняется, то последовательность обхода узлов осуществляется снизу вверх и слева направо.Следующий пример показывает дерево запроса для утверждения SQL, которое получает имена авторов книг, опубликованных в 1993 году:
SELECT A.NAME FROM AUTHORS A, BOOCKS B WHERE (B.DATE_PUBLISHED ='1993') AND (A.NAME = B.NAME);
Рис. 15.1. Дерево запроса
Другие физические встроенные операции
Две наиболее часто используемые реляционные операции - выборка и проекция - реализованы с помощью других физических операций. Это позволяет оптимизатору выполнять эти операции за наименьшее возможное время в плане доступа, непосредственно ограничивающего количество данных, которым остаток плана должен управлять. Реализация операции проекции далее усиливает выполнение доступа только через индекс, когда это подходит.Выборка (Select). Операция выборки ограничивает доступ к строкам, которые не удовлетворяют логике предиката запроса. Эти предикаты оцениваются как можно раньше при выполнении запроса, который поступает обычно, когда строка, содержащая колонки в предикате, обрабатывается в первый раз. Каждый физический оператор доступа к файлу в SQLBase проверяет предикат для фильтрования строк при обработке таблицы. Если предикаты в запросе являются конъюнкцией, формируется логика, называемая обрыванием логической цепочки (short-circuit), для тестирования обрабатываемых строк. Это позволяет отказаться от обработки строк, как только встречается первое несоответствие условию запроса.
Когда оптимизатор оценивает стоимость запроса, действие предикатов, используемое в операции выборки, принимается во внимание посредством статистики, называемой фактором селективности (selectivity factor). Это отношение представляет собой пропорцию строк в таблице, которые, как можно было ожидать, будут выбраны в конкретном предикате. Оптимизатор делает свои оценки этого фактора на основе статистики, связанной с индексами таблицы и некоторыми эвристиками, касающимися операций сравнения предикатов.
Проекция (Project). Операция проекции реализуется совместно с другими физическими операторами, передавая им список колонок, которые должны быть выбраны. Этот оператор затем только включает эти колонки в свой выходной файл. Выполнение проекции как можно раньше в плане запроса ограничивает ширину временной таблицы и результирующего множества, таким образом экономя пространство в памяти и на диске. Заметим, что одним посторонним действием выполнения проекции во время доступа к странице является возможное ограничение ввода/вывода благодаря отказу от доступа к экстентам или страницам LONG VARCHAR, которые не содержат требуемых колонок.
Доступ к таблице только через индекс (Index-only table access). Одним из эффектов встраивания операции проекции в другие физические операции является возможность выполнить доступ только через индекс. Это случается тогда, когда колонки, специфицируемые в проекции, все представлены в индексе. Этот индекс также можно использовать, когда предикат требуется для операции выборки. Когда это происходит, оптимизатор решает, что требования к данным запроса могут быть удовлетворены без доступа к страницам данных таблицы. Это может привести к значительному сокращению операций ввода/вывода, в зависимости от числа строк, которые удовлетворяют предикату запроса.
Физические операции
Когда SQLBase выполняет план запроса, она читает план и вычисляет каждый указанный пункт плана. Каждый из этих пунктов плана сообщает SQLBase, какую операцию нужно выполнить на этом шаге и какие ввод и вывод требуются. При выполнении плана запроса, SQLBase использует физические операции (physical operators). Эти операции отличаются от логических операций, таких как утверждения SQL, определяющих реляционные операции, которые следует выполнить. Для каждой возможной логической операции существует по крайней мере одна и, возможно, много физических операций, которые позволяют СУБД выполнять операцию эффективным способом.Каждая физическая операция имеет один или два входа, в зависимости от природы операции. Также она имеет одну таблицу на выходе (которая, конечно, может содержать одну единственную строку или вовсе не содержать строк). Эта выходная таблица может быть результирующим множеством, которое представляет окончательный вывод для запроса, или может быть промежуточной таблицей, которая будет использована как вход для некоторой операции согласно плану запроса. Одному плану запроса может соответствовать много таких промежуточных таблиц. Они могут быть сохранены в кэш-памяти СУБД или во временном файле на диске. Когда шаг плана запроса завершает выполнение, временные входные таблицы удаляются из памяти или диска.
Языки обработки данных и задача оптимизации обработки данных
Базы данных (БД) можно рассматривать как коллекции данных, предназначенных для совместного, коллективного использования в организации. Это предполагает, что БД представляет собой именованную, структурированную и интерпретируемую совокупность данных пользователей. Физически данные в базах данных представляются в машиночитаемой форме. Логическая структура данных и доступ к ним поддерживаются СУБД. Доступ к данным посредством СУБД осуществляется с помощью языков обработки (манипулирования) данными. Язык манипулирования данными используется для обеспечения доступа к данным при их сохранении в БД или выборки из нее.Независимо от того, является ли БД распределенной или централизованной, данные размещаются в файлах операционной системы компьютера (компьютеров). Ввод/вывод и актуализация данных в БД, поиск данных, требуемых при чтении, добавление новых, модификация существующих и удаление потерявших актуальность осуществляется СУБД и требует разделения используемых ресурсов процессоров, памяти и средств связи. Производительность информационной системы с базами данных определяется через среднее время реакции системы на выполнение операции поиска и предоставления требуемой информации. Время реакции системы зависит от множества факторов, таких как пропускная способность сети, пропускная способность СУБД, мощности процессоров используемых компьютеров, скорости чтения / записи на физические носители и т.д. Она также зависит от логической структуры БД и языковых средств доступа к данным.
Поэтому, для того чтобы лучше понять суть процессов оптимизации запросов в реляционных БД, необходимо сначала обсудить основные типы языков манипулирования данными. В настоящее время различают два основных типа таких языков: процедурные и декларативные.
Обзор оптимизатора запросов
В следующих разделах лекции на примере оптимизатора запросов СУБД SQLBase мы расскажем об общих принципах работы оптимизаторов. Оптимизатор запросов SQLBase (далее просто - оптимизатор) является специфической реализацией оптимизатора, основанного на вычислении стоимости, который принимает свои решения о выборе пути доступа на основе оценок потенциальной стоимости, связанной с выполнением конкретного плана доступа.Основой этих стоимостных оценок является статистика, содержащаяся в системном каталоге SQLBase и областях управления базой данных. Преимущество такого подхода состоит в том, что решения о плане доступа могут быть сделаны на очень новой информации, связанной с действительным содержанием базы данных. Насколько нова и точна эта информация, зависит от процедур, которым вы следуете в администрировании вашей базы данных.
Также будут изложены основы реализации реляционных операций SQL, с последующим изложением методов, которые использует SQLBase при фактическом выполнении этих операторов. Это множество методов, называемое физическими операторами (physical operators), является последовательностью действий, которые рассматривает оптимизатор, когда строит план доступа.
Сначала мы рассмотрим, как выполняются физические операторы. Мы также кратко суммируем основные факторы, включая стоимость каждого из них (обычно в терминах ввода/вывода). В завершении будет объяснена структура плана доступа, с акцентом на эвристиках, используемых оптимизатором при построении множества планов доступа, для которых выполняется анализ стоимости.
На протяжении всех остальных трех частей примеры, которые иллюстрируют операции оптимизатора, обычно используют команду SELECT. Однако следует помнить, что все команды манипулирования данными (DML), т.е. команды INSERT, UPDATE, DELETE, обрабатываются оптимизатором.
Последовательность действий, используемая при обработке этих команд, виртуально идентична последовательности действий при обработке команды SELECT, с той лишь разницей, что должны быть выполнены операции блокировки и записи в журналы транзакций во время операций модификации данных. Преимущество использования команды SELECT для примеров состоит в том, что она охватывает многие реляционные операции, такие как соединение, которое более сильно влияет на характер процесса оптимизации по сравнению с другими командами DML.
Вторым преимуществом использования команды SELECT для примеров является то, что выполнение этой команды приводит к созданию результирующего множества, которое визуально показывает окончательный результат обработки запроса. Это является контрастом по сравнению с другими командами DML, которые изменяют состояние базы данных, но эти изменения не являются визуальными за исключением сообщений об ошибках или значениях встроенных переменных. Только команды SELECT будут визуально отражать эти изменения в содержании базы данных, сделанные при выполнении других команд DML.
Операции доступа к диску
Эта группа физических операций предусмотрена для выборки строк из одной таблицы. Эти строки затем могут либо быть обработаны на других шагах плана запроса, либо составлять окончательное результирующее множество в зависимости от обработки утверждения SQL. Однако операции доступа к диску являются полностью обеспечивающими извлечение данных с диска. Следовательно, каждая из этих операций всегда появляется в качестве первого шага плана запроса, для того чтобы выполнить доступ к данным какой-либо таблицы, которую оптимизатор решает обработать первой.К операциям доступа к диску относятся следующие операции.
Сканирование таблицы (Table scan). Эта операция является простейшим методом доступа к физической таблице. Каждая страница данных, связанная с таблицей, читается. Для каждой страницы строки из нее экстрагируются для обработки. Заметим, что такое экстрагирование может потребовать доступа к дополнительным страницам, представляющим либо страницы экстентов, либо страницы переполнения. В отсутствии страниц экстентов или страниц переполнения число доступов к диску, требуемых для сканирования данных, равно числу страниц данных, назначенных таблице, включая страницы, необходимые для колонок типа LONG VARCHAR, которые могут быть указаны.
Сканирование нижнего уровня индекса (Index leaf scan). Этот метод доступа используется когда определенная последовательность расположения строк таблицы желательна, и индекс обеспечивает эту последовательность, но не существует никаких предикатов для поиска в таблице, которые затрагивают колонки индекса. Другими словами, этот метод доступа может заменить операцию сортировки, если индекс соответствует желаемой последовательности расположения строк.
Основой этого метода является физический метод доступа на основе В+-дерева, который связывает вместе страницы листьев дерева. Этот связный список страниц листьев называется последовательным подмножеством индекса (sequence set). Он строится в соответствии с последовательностью ключа, для каждой из узловой строки индекса, доступной как узел при обработке.
Это означает, что наихудший случай оценки ввода/вывода есть число страниц листьев в индексе плюс число строк в таблице. Это число иногда может быть увеличено, если таблица полностью или частично разбита на кластеры в индексной последовательности. Вы увидите, как оптимизатор оценивает эту возможность далее.
Сканирование индекса (Matching index scan). Сканирование индекса использует полные возможности индексной структуры В+-дерева в SQLBase. Этот метод доступа используется, когда утверждение SQL требует только часть таблицы для обработки, основываясь на предикате, который использует колонки, представленные в индексе. Так как генетические возможности индексов В+-дерева эксплуатируются SQLBase, этот метод доступа может использоваться для любого индекса, который имеет колонку из предиката в наиболее левой позиции ключа. Оптимизатор обычно использует этот метод доступа, если предикаты значительно ограничивают объем ввода/вывода на индексе. Также, если предикат неравенства применяется для некоторой колонки индекса, этот метод использует дерево индекса для того, чтобы найти начальный лист, и затем сканировать последовательное подмножество индекса вперед или назад от найденной точки.
Число операций ввода/вывода, необходимое в этом методе доступа, есть число операций для каждого уровня плюс число операций для каждого узла индекса, к которому получен доступ, плюс число операций для каждой строки, которая должна попасть в выборку. Оптимизатор оценивает стоимость для этого метода доступа, используя статистику обработки индекса, называемую фактором селективности (selectivity factor). Короче говоря, фактор селективности описывает ожидаемое число строк в таблице, которое должно удовлетворять условию поиска.
Хэширование (Hash access). Таблица, которая имеет кластеризованный хэш-индекс на ней, может быть доступна через этот индекс, когда все колонки, содержащиеся в индексе, используются в предикате равенства утверждения SQL. Реализованный метод хэширования не обладает какими-либо генетическими или сканирующими механизмами.Это объясняет, почему ключ такого индекса должен быть полностью указан в предикате равенства в утверждении SQL.
Если какие-либо ограничивающие условия использования кластеризованного хэш-индекса будут обнаружены, то, вероятно, наиболее быстрые альтернативы для доступа к таблице будут выбраны оптимизатором. Стоимость ввода/вывода этого метода доступа есть число операций для каждой строки или множества строк, которые имеют ключ, указанный в предикате. Дополнительная стоимость ввода/вывода может потребоваться для поиска в цепочке переполнения, если таблица хэширования имеет большое число коллизий, и этот условие может вынудить оптимизатор отказаться от этого метода доступа.
Операции соединения
Соединение отношений является наиболее часто выполняемой операцией в любой реляционной базе данных. Она также может требовать для выполнения много времени из-за того, что наиболее простейшая реализация операции соединения требует многократного просмотра всех строк одной из таблиц. SQLBase планирует выполнение этой операции исходя из ряда альтернативных путей доступа к данным. Все используемые операции имеют на входе две таблицы и одну таблицу на выходе. Эти входные и выходные таблицы могут быть комбинацией таблиц БД, временных таблиц и результирующего множества.Терминология, общая для всех алгоритмов соединения, есть именование участвующих таблиц. Так как строка одной таблицы должна сравниваться с каждой строкой другой таблицы, то таблица, строка которой запоминается, называется внешней таблицей. Таблица, которая сканируется для этой запомненной строки, называется внутренней таблицей.
К операциям соединения относят следующие физические операции.
Простой алгоритм соединения в цикле (Simple loop join). Этот алгоритм является простейшим прямолинейным методом соединения двух таблиц. Он может иметь наихудшую стоимость выполнения для операции соединения, особенно если входные таблицы большие. Одно из преимуществ простого соединения в цикле состоит в том, что он может быть использован независимо от типа критерия соединения, наличия или отсутствия индексной структуры. Также существуют ситуации, где данный алгоритм может иметь лучшую производительность, в частности, если одна из входных таблиц помещается в кэш-память.
Алгоритм соединения в цикле получает строку из внешней таблицы, затем полностью сканирует внутреннюю таблицу для того, чтобы найти строки, удовлетворяющие критерию соединения. Когда критерий удовлетворяется, строки добавляются и выводятся. При достижении конца внутренней таблицы получается новая строка из внешней таблицы, и сканирование внутренней таблицы начинается снова.
Благодаря вложенной циклической структуре метода наихудший случай для числа операций ввода/вывода есть число страниц данных во внутренней таблице, умноженное на число страниц данных во внешней таблице.
Это может быть не так драматично, если внутренняя таблица невелика и полностью размещается в кэш-памяти. Тогда число операций ввода/вывода сокращается до суммы числа страниц данных внешней и внутренней таблиц. По этой причине SQLBase всегда выбирает меньшую из двух таблиц в качестве внутренней для размещения ее в кэш-памяти. Когда кэш-памяти достаточно для размещения одной из таблиц, то этот метод становится более предпочтительным по стоимости, чем другие.
Два следующих метода соединения являются производными из основного метода циклического соединения. Они могут быть использованы, когда подходящий индекс имеется для таблиц и можно увеличить скорость операции соединения значительно по сравнению с методом простого циклического соединения.
Циклическое соединение с индексом (Loop join with index). Вариант вложенного циклического соединения может быть применен, когда существует индекс для одной из таблиц, который построен на колонках соединения по возрастанию значений ключа. Когда есть такая ситуация, оптимизатор использует таблицу с индексом как внутреннюю таблицу для алгоритма циклического соединения, и задействует индекс для того, чтобы ограничить поиск строк, соответствующих текущей удерживаемой строке из внешней таблицы. Это значительно уменьшает число операций ввода/вывода, необходимых для обработки внутренней таблицы. Наилучшим случаем является ситуация, когда внутренняя таблица кластеризована и обрабатывается эквисоединение, тогда объем ввода/вывода равен сумме числа страниц данных в двух таблицах, плюс высота дерева индекса, плюс число строк во внешней таблице. Последние две компоненты стоимости вычисляются для оценки доступа к индексной структуре во время реализации соединения строки.
Циклическое соединение с хэш-индексом (Loop join with hash index). Эта разновидность метода циклического соединения может применяться, когда одна из соединяемых таблиц имеет CHI. Два других требования к этому методу состоят в том, что хэш-индекс должен быть создан для всех колонок из критерия соединения (и никаких других) и соединение должно являться эквисоединением.
Когда эти условия выполняются, этот метод соединения может быть очень эффективным. Наихудший случай есть ситуация, когда число операций в/в равно числу страниц данных во внешней таблице плюс число строк во внутренней таблице. Это происходит только в случае ввода/вывода, если каждая строка во внутренней таблице ссылается на внешнюю таблицу. Когда не все строки внутренней таблицы ссылаются на внешнюю таблицу, то число операций ввода/вывода ограничивается.
Соединение посредством объединения индекса (Index merge join). Этот метод может быть использован, когда существуют индексы для колонок критерия соединения обеих таблиц. Основной алгоритм состоит в сканировании подмножества последовательности этих двух индексов и объединении строк из таблицы, основываясь на соответствие ее критерия соединения. Например, когда обрабатывается эквисоединение, то сначала вход индекса читается из последовательности листьев внешней таблицы. Затем вход читается из последовательности листьев внутренней таблицы. Если колонка соединения внутренней таблицы меньше, чем внешней, то сканирование внутренней таблицы продолжается. Если больше, то сканируется последовательность листьев внешней таблицы до тех пор, пока значение, равное или большее, не будет найдено. Когда колонки соединения в обоих индексах удовлетворяют критерию соединения, строки таблиц читаются из страниц данных, добавляются одна к другой и записываются в выходную таблицу.
Стоимость ввода/вывода этого метода зависит от того, как много строк таблиц удовлетворяют критерию соединения. Наилучший случай есть эквисоединение первичного ключа, когда стоимость равна числу терминальных узлов в двух последовательных подмножествах плюс число строк в обеих таблицах. Если таблицы также кластеризованы в последовательных подмножествах, число операций ввода/вывода для выборки строки сводится к числу страниц данных, распределенных по двум таблицам, плюс сумма страниц листьев в обеих индексах.
Соединение хэширования (Hash join). Этот метод может быть использован только для эквисоединения и не требует каких-либо индексов для колонок критерия соединения двух таблиц.Алгоритм сначала выполняет фазу установки, когда сканируется внешняя таблица и каждая строка помещается в хэш-таблицу согласно значению хэш-функции для критерия соединения. Наименьшая таблица всегда выбирается как внешняя, для того чтобы минимизировать память под хэш-таблицу.
На второй фазе, называемой проба (probe), внутренняя таблица сканируется, и хэш-функция используется для выборки возможных значений. Любая строка, найденная в хэш-бакете для первой таблицы, затем проверяется. Строки, которые удовлетворяют критерию поиска, добавляются к строке внутренней таблицы и записываются в выходную таблицу.
Это может быть очень быстрым методом соединения, особенно когда меньшая таблица может быть хэширована в таблицу в оперативной памяти. Когда это возможно, стоимость ввода/вывода равна сумме страниц данных двух таблиц. С другой стороны. дополнительный ввода/вывода требуется при разбиении хэш-таблицы на сегменты, а также для управления ими во временном файле на диске.
Оптимизация, основанная на правилах
Когда был достигнут некоторый прогресс в улучшении обработки запросов, были предприняты и усилия для улучшения методов доступа к таблицам. Это касается разработки методов доступа на основе использования индексов и функций хэширования. Однако использование техники индексирования и хэширования увеличивает сложность обработки запроса. Например, если таблица имеет индексы по трем различным колонкам, то любой из них может быть использован для доступа к таблице (помимо последовательного доступа к таблице в физическом порядке расположения строк).Кроме того, появилось много новых алгоритмов для выполнения соединения таблиц. Двумя наиболее основными алгоритмами выполнения соединения являются:
Операции соединения подчиняются как коммутативному, так и ассоциативному закону. Следовательно, теоретически возможно выполнять соединение в любом порядке. Например, все следующие предложения являются эквивалентными:
(A JOIN B) JOIN C A JOIN (B JOIN C) (A JOIN C) JOIN B
Однако различные пути доступа, алгоритмы соединений и порядок выполнения соединений могут приводить и к различной производительности.
Следовательно, когда выполняется соединение нескольких таблиц, каждая из которых имеет несколько индексов, то существует несколько сотен различных комбинаций для выбора порядка выполнения соединений, алгоритмов соединений и путей доступа осуществления выборки. Каждая из этих комбинаций производит один и тот же результат, но с различными характеристиками производительности.
Одним из первых подходов на пути борьбы с комбинаторной сложностью выполнения соединений состоит в установлении эвристических правил для выбора между путями доступа и методами соединений, которая называется оптимизацией, основанной на правилах (rule-based optimization). В этом подходе веса и предпочтения назначаются альтернативам на основе принципов, которые являются общепризнанными. Используя эти веса и предпочтения, оптимизатор запросов производит возможные планы выполнения до тех пор, пока не будет достигнут лучший план выполнения, удовлетворяющий этим правилам. Некоторые из этих правил, используемых оптимизаторами такого типа, основываются на размещении переменных служебных символов (variable tokens), таких как имена таблиц и колонок в синтаксических структурах запроса. Когда эти имена размещаются, иногда может существовать значительная разница в производительности выполнения запроса. По этой причине оптимизаторы, основанные на правилах, как говорят, являются синтаксически зависимыми, и одним из методов настройки оптимизаторов этого типа СУБД является размещение символов (tokens) в различных позициях внутри утверждения.
Оптимизация, основанная на правилах, обеспечивает удовлетворительную производительность системы в тех ситуациях, когда эвристики являются точными. Однако часто общепризнанные правила не являются точными. Для обнаружения таких ситуаций оптимизатор запросов должен рассматривать характеристики данных, такие как:
Эти характеристики данных могут сильно влиять на эффективность обработки запроса. Использование таких характеристик приводит к следующему типу оптимизации.
Оптимизация, основанная на вычислении стоимости
Оптимизация, основанная на вычислении стоимости запроса (cost-based optimization), аналогична оптимизации, основанной на правилах, за исключением того, что оптимизатор на основе вычисления стоимости использует статистическую информацию для выбора наиболее эффективного плана выполнения запроса. Стоимость каждого альтернативного плана выполнения запроса оценивается с помощью статистики, такой как число строк в таблице и числа и распределения значений колонки таблицы. Формулы стоимости обычно учитывают количество ввода/вывода и время CPU, необходимое для выполнения плана запроса. Такая статистика хранится в системном каталоге и поддерживается СУБД.Для понимания того, как статистика может быть использована для выбора плана выполнения запроса, рассмотрим следующий запрос к таблице CUSTOMER (ПОКУПАТЕЛЬ):
SELECT CUST_NBR, CUST_NAME FROM CUSTOMER WHERE STATE = "FL";
Если индекс существует на колонку STATE, оптимизатор, основанный на правилах, использовал бы его для обработки запроса. Однако если девяносто процентов строк в таблице CUSTOMER имеют FL в колонке STATE, то использование индекса будет в действительность приводить к более медленному выполнению запроса, чем простая последовательная обработка таблицы. Оптимизатор, основанный на вычислении стоимости, с другой стороны, обнаружил бы, что использование индекса не дает никаких преимуществ перед последовательным просмотром таблицы.
Подход к оптимизации, основанный на вычислении стоимости, сегодня представляет определенное искусство в технике оптимизации запросов. Большинство реляционных СУБД применяют оптимизаторы, основанные на вычислении стоимости.
Оптимизация запросов
Компонента SQL СУБД, которая определяет, как осуществлять навигацию по физическим структурам данных для доступа к требуемым данным, называется оптимизатором запросов (query optimizer).Навигационная логика (вариант алгоритма) для доступа к требуемым данным называется путем или методом доступа (access path).
Последовательность выполняемых оптимизатором действий, которые обеспечивают выбранные пути доступа, называется планом выполнения (execution plan).
Процесс, используемый оптимизатором запросов для определения пути доступа, называется оптимизацией запросов (query optimization).
Во время процесса оптимизации запросов определяются пути доступа для всех типов команд SQL DML. Однако команда SQL SELECT представляет наибольшую сложность в решении задачи выбора пути доступа. Поэтому этот процесс обычно называют оптимизацией запроса, а не оптимизацией путей доступа к данным. Далее следует отметить, что термин оптимизация запросов является не совсем точным в том смысле, что нет гарантии, что в процессе оптимизации запроса будет действительно получен оптимальный путь доступа. Более подходящим термином мог бы быть термин "улучшение запроса" (query improvement). Например, наилучший возможный путь доступа, имеющий заданную стоимость (в смысле вычислительной сложности). Далее всюду используется стандартный общепринятый термин "оптимизация запросов" во избежание недоразумений.
Ранние версии реляционных СУБД обрабатывали запросы простым и непосредственным способом без какой-либо попытки оптимизировать как запрос сам по себе, так и путь доступа. Это имело результатом неудовлетворительно большое время обработки запроса и приводило к убеждению среди некоторых прикладных программистов, что реляционные СУБД являются непрактичными и мало пригодными для широкого круга практических применений. Для того чтобы увеличить скорость обработки запросов, были выполнены обширные исследования и тестирование для поиска способов повышения эффективности обработки запросов.
Таким образом, оптимизация запросов может быть определена как сумма всех технических приемов, которые применяются для повышения эффективности обработки запросов.
Последовательность шагов оптимизации запросов
Несмотря на то, что оптимизаторы запросов современных реляционных СУБД различаются по сложности и принципам создания, все они следуют одним и тем основным этапам в выполнении оптимизации запроса.Так как шаги 1 и 2 имеют место независимо от действительных данных, находящихся в таблицах, нет необходимости повторять их, если запрос не требует перекомпиляции. Следовательно, большинство оптимизаторов будут сохранять результаты 2-го шага и использовать его снова, когда они переоптимизируют запрос в другой раз.
Построение дерева запроса
Когда оптимизатор строит деревья запросов для оценки стоимости и возможного окончательного выбора, он использует некоторые правила, которые управляют размещением различных узлов дерева. Эти правила позволяют оптимизатору ограничить число узлов дерева запросов, которые строятся для дальнейшего решения задачи оценки стоимости. Ограничивая возможные альтернативы путей доступа таким образом, оптимизатор может выполнить обработку более эффективным способом.Одна из важнейших эвристик состоит в использовании правил, таких как выполнение операций проекции и выбора как можно раньше. Это так, потому что эти операции могут ограничить размер результирующего множества. На рис. 15.2 оптимизатор улучшает дерево запросов, применяя выборку сначала для ограничения числа строк, которые являются входом операции эквисоединения.
SELECT A.NAME FROM AUTHORS A, BOOCKS B WHERE (B.DATE_PUBLISHED ='1993') AND (A.NAME = B.NAME);
Рис. 15.2. Использование эвристических правил для увеличения эффективности запроса
Следовательно, когда несколько операций выборки выполняется в запросе для доступа к таблице, операции с наименьшим значением фактора селективности выполняются позже по дереву для того, чтобы ограничить размер промежуточных результатов как можно раньше по мере возможности. Конечно, предикаты могут быть оценены в зависимости от того, когда все данные, указываемые в предикате, являются доступными. SQLBase преобразует некоторые предикаты для того, чтобы оценить затем их как можно раньше.
Преобразование логики предиката
Когда несколько предикатов указаны в реляционной операции выборки, важная эвристика состоит в том, чтобы преобразовать их в эквивалентные условия в конъюнктивной форме, которая состоит в перегруппировке логических условий в предикате. Например,WHERE COL1 > 5 OR (COL2 < 500 AND COL3 >150)
может быть переписано как
WHERE (COL1 > 5 OR COL2 < 500) AND ( COL1 >5 OR COL3 <150).
Конъюнктивная форма является предпочтительнее, так как может быть оценена с помощью метода укороченной цепочки. Набор предикатов в конъюнктивной форме будет истинным только и только тогда, когда каждая компонента с OR будет истинной. Так как число операций сравнения, которое выполняется для запроса, прямо влияет на время CPU, использование метода укороченной цепочки для конъюнктивной формы представления предикатов может сократить число циклов CPU.
Литература: [7], [23].
Процедурные языки обработки данных
Большинство систем БД до начала использования SQL-технологии основывались на процедурных или навигационных языках обработки данных. Примерами таких систем БД могут служить ADABAS (Software Ag.), IDMS, IMS (IBM Corp.) и dBase. Процедурные языки обработки данных требуют от программиста кодирования программной логики, необходимой для навигации по физической структуре данных для идентификации и доступа к требуемым данным. Например, при использовании ADABAS программист должен написать код для спецификации записей данных (FIND), получить специфицированное множество данных и организовать цикл его просмотра (GET), а также предоставить код для актуализации полученных данных для пользователя.Если прикладная программа ссылается на физические структуры данных, то она естественно становится зависимой от них. Такие прикладные программы требуют модификации кода, если изменяется физическая структура данных. Например, если индекс в dBase удаляется, то все прикладные программы, которые его используют, должны быть модифицированы.
Зависимость между прикладной программой и физической структурой данных значительно увеличивает стоимость разработки и сопровождения таких программ. Во время разработки больших, сложных компьютерных систем очень часто обнаруживается несоответствие в спроектированной физической структуре БД и реализации в программах функциональности предметной области на различных этапах выполнения проекта. Для устранения таких несоответствий администратор БД должен осуществлять изменения физической структуры.
Такие изменения физической и логической схем БД вступают в противоречия со всеми существующими программами, которые ссылаются на эти измененные физические структуры. Эти программы должны быть модифицированы для того, чтобы отразить изменения в схеме БД. Если прикладная программа в значительной мере использует эту измененную физическую структуру для навигации по БД и программная логика основывается на этой навигации, то может потребоваться значительное перекодирование программы. С другой стороны, сопровождение существующих систем часто приводит к изменениям схемы БД, и, следовательно, такая зависимость приводит к увеличению стоимости сопровождения пользовательских приложений.
В дополнение к сказанному, процедурные языки обработки данных обычно являются контекстно-зависимыми в реализации. Следовательно, прикладные программы становятся полностью привязанными к конкретной системе БД, для которой они и были разработаны. Такая привязка прикладных программ к конкретным системам БД значительно ограничивает их мобильность.
Реляционные операции
Основные операторы реляционной алгебры были определены Э.Ф. Коддом, когда он опубликовал свою основополагающую работу по языкам манипулирования данными в реляционной модели в 1972 году. Операции, определенные в этой реляционной алгебре, формируют логические операторы, которые должны быть обработаны оптимизатором. Эти логические операторы являются неявными для синтаксиса команд SQL DML, но именно они и обрабатываются СУБД.Операции реляционной алгебры имеют на входе одно или более отношений на входе и одно отношение на выходе. Отношением является просто таблица некоторой степени n, где n - число атрибутов (или колонок) в таблице. Эти операторы разделяются на два класса: теоретико-множественные операции (traditional set operations) и специальные реляционные операторы (special relational operators). В то время как использование теоретико-множественных операций обычно достаточно для обработки большинства реляционных запросов, специальные операторы определяют желаемый результат более эффективно. Этот последний класс будет изучен в этом разделе более подробно, в то время как теоретико-множественные операции будут определены в общих чертах (предполагается, что они хорошо известны после изучения предыдущих л екций этого курса).
Синтаксическая оптимизация
Первый успех в оптимизации запросов состоял в нахождении способа переформулирования запроса таким образом, чтобы новое представление запроса обеспечивало тот же результат, но было более эффективно для обработки СУБД.Пример. Рассмотрим следующий запрос, который делает выборку данных из таблиц PRODUCT (ПРОДУКЦИЯ) и VENDOR (ПРОИЗВОДИТЕЛЬ):
SELECT VENDOR_CODE, PRODUCT_CODE, PRODUCT_DESC FROM VENDOR, PRODUCT WHERE VENDOR.VENDOR_CODE = PRODUCT.VENDOR_CODE AND VENDOR.VENDOR_CODE = "100";
Наиболее очевидный путь обработки этого запроса состоит в следующем:
Оценим стоимость процесса обработки этого запроса в терминах операций ввода/вывода. Пусть для определенности таблица VENDOR содержит 50 строк, а таблица PRODUCT - 1000 строк. Тогда формирование декартова произведения потребует 50050 операций чтения и операций записи (в результирующую таблицу). Для ограничения результирующей таблицы потребуется более 50000 операций чтения и, если 20 строк удовлетворяют условиям поиска, то 20 операций записи. Выполнения операции проекции вызовет еще 20 операций чтения и 20 операций записи. Таким образом, обработка этого запроса обойдется системе в 100090 операций чтения и записи.
Основная идея синтаксической оптимизации лежит в использовании эквивалентных алгебраических преобразований. SQL является алгебраическим языком манипулирования множествами (представленными таблицами). Каждый оператор SELECT эквивалентен некоторой формуле этого языка. Существует набор алгебраических правил для тождественных преобразований формул над множествами. Для данного примера запроса можно использовать следующую эквивалентность:
(A JOIN B) WHERE restriction on A v (A WHERE restriction on A) JOIN B.
Это означает, что ограничение по условию поиска может быть выполнено как можно раньше для того, чтобы ограничить число строк, которые могут быть обработаны позже.
Применяя это правило к запросу, приведенному выше, получаем следующий процесс обработки запроса:
Обработка запроса в этом случае потребует 1120 операций чтения и 40 операций записи для получения того же самого результата, что и в первом случае. Преобразование, описанное в данном примере, называется синтаксической оптимизацией (syntax optimization).
Существует много формул для выполнения таких преобразований, и все современные оптимизаторы запросов используют правила преобразований для представления запроса в более эффективной форме для обработки. С точки зрения реализации является очень важным, что эти автоматические преобразования освобождают программиста от поиска эквивалентной формы запроса, чтобы получить самую лучшую реализацию, поскольку оптимизатор обычно дает такую же окончательную форму, какую вы можете получить вручную.
Сортировка и агрегация
Операция сортировки производится, когда таблица должна быть представлена в определенной последовательности в соответствии со значениями одной или более колонок, которые все вместе называются ключом сортировки (sort key). Эта физическая операция имеет одну таблицу на входе и одну таблицу на выходе.Операция агрегирования также имеет одну таблицу на входе и одну таблицу на выходе. Физическая операция агрегирования SQLBase выполняет последовательное сканирование квалифицируемых строк данных, с вычислением агрегатной функции для каждой строки. Когда выполняется скалярная агрегация, входные строки могут располагаться в любой последовательности. Однако при групповой агрегации, когда функция агрегирования вычисляется, входная таблица должна быть представлена в последовательности значений колонки, указанной в предложении GROUP BY.
Это требование удовлетворяется оптимизатором запросов путем либо размещения операции сортировки до выполнения операции агрегирования, либо использования такого метода доступа к таблице, который возвращает строки таблицы в указанной последовательности.
Специальные реляционные операторы
SQL использует этот класс операций гораздо чаще, чем теоретико-множественные операции. К классу специальных реляционных операций обычно относят следующие:Операция проекции ограничивает число колонок таблицы, на которые ссылаются в команде SQL.
Операция выбора ограничивает результирующее множество только теми строками, которые удовлетворяют условию поиска. Критерий поиска представляет собой сравнение одной или более колонок таблицы либо с одной, либо с несколькими константами или выражениями.
Операция соединения создает результирующее множество посредством конкатенации строк нескольких таблиц. Эти сцепленные строки должны удовлетворять некоторому условию соединения, которое является сравнением одной или более колонок этих таблиц. Эти операции сравнения в условиях соединения отличаются от операций сравнения в условиях поиска в том, что сравнивают значения колонок различных таблиц.
Поскольку эти специальные реляционные операции играют центральную роль в командах SQL, то рассмотрим их более подробно.
Проекция. Когда SELECT специфицирует определенные колонки из одной или более таблиц, то выводятся только значения этих колонок:
SELECT NAME, PHONE FROM CUSTOMER;
Альтернативой к выполнению проекции является использование символа "*", который приводит к выводу всех колонок таблицы:
SELECT * FROM CUSTOMER;
Заметим, что многие вычислительные среды имеют стандарты, препятствующие использованию этой нотации в коде, так как изменение числа колонок в таблице может иметь неблагоприятное воздействие на программу, содержащую такое предложение.
Селекция. Селекция является строковым эквивалентом операции проекции на колонки. В SQL предложение WHERE специфицирует выбор указания имен колонок в выражениях сравнения либо с константами (однозначными или многозначными), либо с выражениями, которые вычисляют одно или несколько значений. Можно привести следующие примеры операции селекции:
SELECT * FROM CUSTOMER WHERE NAME = 'JONES'; SELECT * FROM PRODUCT WHERE STOCK_QTY <= REORDER_QTY; SELECT * FROM ORDER WHERE (STАTUS IN ('C','P','S')) AND (TOTAL_AMT > 1000);
Каждое сравнение, содержащееся в предложении WHERE, называется предикатом (predicate). Некоторые команды SQL, подобно последней в приведенных примерах, содержат более одного предиката. Когда операция, указанная в предикате, выполняется на строке, то это называется взятием предиката (applying the predicate). Если предикат вычисляется как TRUE, то говорят, что условие выбора удовлетворено, в противном случае - не удовлетворено. Когда утверждение имеет более чем один предикат, они должны быть связаны одним или боле логическими операторами AND или OR. Когда все предикаты связаны операцией AND, то говорят, что это конъюнкция (conjunctive), когда OR, то говорят, что это дизъюнкция (disjunctive). Эта терминология предикатов играет важную роль в том, как они используются оптимизатором запросов.
Заметим, что форма предложения WHERE, которая сравнивает колонки из различных таблиц, не является операцией селекции, но является спецификацией для операции соединения.
Соединение. Соединение создает результирующее множество из двух или более таблиц таким же образом, что и ранее рассмотренное декартово произведение. Оно осуществляет конкатенацию строк для каждой строки одной таблицы с каждой строкой другой таблицы. Отличие между декартовым произведением и соединением состоит в том, что в эту операцию вовлекаются только те строки, которые удовлетворяют условию соединения. Это является логическим эквивалентом декартова произведения, для которого операция селекции по условию была выполнена. Однако операция соединения реализуется более эффективно большинством оптимизаторов запросов, так как оценивание строк выполняется до первоначального формирования декартова произведения как промежуточного результата.
Для того чтобы выполнить соединение, используются предложения FROM и WHERE команды SELECT. Предложение FROM должно именовать каждую входную таблицу соединения. Предложение WHERE специфицирует критерий соединения посредством сравнения одной или более колонок одной таблицы с одной или более колонками другой.
Предикаты, используемые в качестве критерия соединения, определяют, как много строк декартова произведения будут пропущены при обработке соединения. Чем более ограничительным будет являться критерий соединения, тем более эффективно будет выполняться соединение. Приведем примеры соединений.
SELECT NAME, AMOUNT FROM CUSTOMER, RECEIVABLE WHERE CUSTOMER.CUST_NO = RECEIVABLE. CUST_NO; SELECT NAME, QTY, DESC FROM CUSTOMER C, ORDER O, PRODUCT P WHERE ( C.CUST_NO = O. CUST_NO ) AND (P.CUST_NO = O. CUST_NO );
Во втором примере буквы С, О, Р позволяют вам квалифицировать имена колонок соответствующих таблиц без указания их полных имен. В SQL это называется корреляционными переменными (correlation variables). Так как большинство имен колонок должны быть квалифицируемыми, то они часто используются в соединениях благодаря представлению нескольких имен таблиц в предложении FROM.
Две важнейших характеристики операции соединения состоят в том, что она является коммутативной и ассоциативной:
A JOIN B = B JOIN A; (коммутативность) A JOIN (B JOIN C) = (A JOIN B) JOIN C; (ассоциативность) (A JOIN B) JOIN C = B JOIN (A JOIN C).
Действие этих свойств состоит в том, что когда оптимизатор обрабатывает соединение более чем двух таблиц, то он может выбрать любую последовательность соединений двух таблиц для завершения операции. Это дает возможность оптимизатору готовить выполнение соединения любого числа таблиц как серию соединений двух таблиц, которое позволяет избегать выполнения специфических физических операций при соединении произвольного числа таблиц.
Тип операции сравнения часто используется для классификации операций соединения.
Эквисоединение (Equijoin). Наиболее общим примером соединения является эквисоединение, которое использует оператор сравнения "=". Эта версия операции соединения применяется, когда взаимосвязь между объектами предметной области требует комбинации информации из двух таблиц по равенству значений в соответствующих колонках. Такие соединения реализуются установкой первичного ключа родительской таблицы равным внешнему ключу таблицы-потомка.
SELECT C.CUST_NO, C.CUST_NAME, O.ITEM_NO, I.DESC FROM CUST C, ORDER O, ITEM I WHERE (C.CUST_NO = O.CUST_NO) AND (O.ITEM_NO = I.ITEM_NO);
SELECT C.CUST_NO, C.CUST_NAME, O.ITEM_NO, I. DESC FROM CUST C, ORDER O, ITEM I WHERE (C.CUST_NO = O.CUST_NO) AND (O.ITEM_NO = I.ITEM_NO);
Естественное соединение (Natural join). Эта форма соединений является частной формой эквисоединения, когда все колонки двух таблиц включаются, за исключением некоторого множество ключевых колонок, которые являются продублированными в обеих таблицах. Это есть полное эквисоединение двух таблиц, без какой либо проекции за исключением оценки дублирования колонок ключей.
Полусоединение (Semijoin). Операция полусоединения эквивалентна эквисоединению с последовательной проекцией, которая включает колонки одной из таблиц соединения. Это полезно, когда нужны строки таблицы, которые включены в критерий поиска и определяются в терминах принадлежности к колонке внешнего ключа другой таблицы. Примером могло бы быть множество всех продуктов, которые были проданы в течение января 1995 года:
SELECT P.PROD_NO, P.PROD_DESC FROM PRODUCT P, ORDER O WHERE (O.PROD_NO = P.PROD_NO) AND (O.ORD_DATE BETWEEN JAN-1-1995 AND JAN-31-1995);
Полусоединения также полезны в распределенных вычислениях, когда две соединяемые таблицы находятся на различных узлах вычислительной сети.
Внешнее соединение (Outerjoin). Внешнее соединение позволяет включать в результирующие множество незадействованные строки (non-participating rows) одной из таблиц, которые не соответствуют условиям соединения. Причина, по которой эти строки называются незадействованными, состоит в том, что они содержат значения ключей, которые не ссылаются на какую-либо строку другой таблицы. Например, строка в множестве товары содержит номер продукта, который никогда не будет учитываться каким-либо производителем, - такая строка была бы незадействованной в соединении таблицы "товары" и таблицы "счета". В SQLBase эти строки могут быть включены в результирующее множество посредством указания оператора внешнего соединения "+", на ключе таблице ORDER, как показано в примере.
SELECT * FROM PRODUCT P, ORDER O WHERE P.PROD_NO = O.PROD_NO(+);
Самосоединение (Selfjoin). Самосоединение является эквисоединением таблицы с самой собой. Это также называется рекурсивным соединением. Заметим, что в этом случае необходимо назначить корреляционные переменные для того, чтобы избежать неправильных ссылок на колонки, как это сделано в следующем примере, который выводит список имен всех служащих и назначенных им руководителей.
SELECET E.NAME, M.NAME FROM EMPLOYEE E, EMPLOYEE M WHERE E.MNGR_NO = M. EMPLOYEE_NO;
Агрегация (Aggregation). Хотя агрегация не была первоначально специфицирована как реляционная операция, ее включение как стандартной возможности SQL сделало ее общераспространенной операцией. Цель агрегации состоит в том, чтобы предоставить для таблицы выведенную статистическую информацию, такую как сумма или среднее множества чисел.
SQL поддерживает два типа агрегации, простейший из которых есть скалярная агрегация, которая производит единственный вывод для колонки отношения. Скалярная агрегация в SQL выполняется посредством включения функций агрегирования в запрос, который не имеет какого-либо предложения GROUP BY. Например:
SELECT SUM(SALARY) FROM EMPLOYEE; SELECT COUNT(*) FROM EMPLOYEE WHERE NAME = 'DAVE';
Первый запрос вычисляет суммарную зарплату всех служащих, в то время как второй запрос говорит, как много служащих имеют имя Dave. Отличающая характеристика этих запросов состоит в указании некоторой агрегатной функции в списке имен предложения SELECT, который позволяет определить интервал для целого результирующего множества доступа к таблице (после выполнения проекций и выбора).
Второй тип агрегации, поддерживаемый SQL, есть функция агрегации. Этот тип агрегации использует такие же агрегатные функции, что и скалярная агрегация. Разница между ними состоит в том, что функция агрегации всегда создает другую таблицу как вывод. Это противоположно скалярной агрегации, которая просто возвращает единственное значение как вывод.
Синтаксис SQL для выполнения функции агрегации всегда включает предложение GROUP BY.Колонки, названные в предложении GROUP BY, становятся в действительности ключом к некоторой новой таблице, которая выводится этим утверждением. Например, функцией агрегирования является
SELECT DEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY DEPT; SELECT @MONTH(BIRTH_DAY), COUNT(*) FROM EMPLOYEE GROUP BY :1;
Здесь первый запрос показывает список отделов и среднюю зарплату по каждому отделу, а второй запрос - список месяцев дней рождения служащих и число дней рождения в каждом месяце в текущем году. В каждом из этих утверждений функция агрегирования варьируется по строкам входной таблицы, которые имеют равные значения в колонке, указанной в предложении GROUP BY.
Структура плана запроса
Когда оптимизатор группирует множество физических операций для выполнения утверждения SQL, то полученная спецификация называется планом запроса (query plan).Аналогия с задачей программирования делает роль плана запроса проще для понимания. Программист кодирует инструкции на языке высокого уровня, которые затем компилируются для получения выполняемого программного кода. Это выполняемая форма использует машинные команды для того, чтобы сказать CPU, что нужно делать. CPU выполняет машинные инструкции, а не первоначальный код.
Аналогично, программист кодирует утверждения SQL, которые затем обрабатываются оптимизатором для производства выполняемой формы этого кода. Эта выполняемая форма кода есть план запроса.
Теоретико-множественные операции
Главное отличие теоретико-множественных операций (за исключением декартова произведения) от всех других, выполняемых СУБД, состоит в том, что отношения, используемые на входе этих операций, должны иметь одинаковое число колонок. При этом каждый соответствующий атрибут определяется на одном и том же домене. Это означает, что каждая таблица должна иметь одинаковое число колонок и каждая пара колонок для любой позиции таблицы должна быть определена с одинаковым типом и масштабом.Объединение двух отношений есть множество всех строк, принадлежащих либо каждому из них, либо обоим вместе. Оно может быть сформировано добавлением одной таблицы к другой и исключением дублированных строк.
двух отношений есть все строки, которые принадлежат первому отношению, но не принадлежат второму. Заметим, что эта операция не коммутативна, т.е. А-В<>В-А.
Декартовым произведением двух отношений является таблица, получаемая конкатенацией каждой строки одной таблицы с каждой строкой другой таблицы. Таблица, получаемая в результате этой операции, содержит число строк, равное произведению числа строк исходных таблиц. Это означает, что если имеется две таблицы с 15 и 50 строками соответственно, то их декартово произведение есть таблица с 750 строками. Как указывалось выше, это единственная теоретико-множественная операция, которая допускает различный формат исходных таблиц.
Основы проектирования реляционных баз данных
Анализ запросов с целью повышения скорости их выполнения
Рассмотрим теперь общую процедуру настройки команды SELECT, результат выполнения которой не удовлетворяет требованиям производительности. Эта процедура является итерацией на пути построения оптимального набора индексов и состоит из семи шагов. При обсуждении этой процедуры мы для простоты будем ориентироваться на СУБД SQLBase.Шаг 1. Обновить статистику. До того как добавить индексы, необходимо убедиться, что статистика базы данных в системном каталоге является корректной. Если вы выполняете запрос без учета действительной производительности базы данных, вам следовало бы обновить статистику для всех таблиц, указанных в предложении FROM, используя команду UPDATE STSTISTICS (для SQLBаse) или другую специальную команду СУБД. С другой стороны, если вы используете небольшую тестовую базу данных, то можно вручную вычислить необходимые статистические показатели и внести их в системный каталог.
Когда вы обновляете статистику, вам следовало бы скомпилировать команду SQL, установив параметр PLANONLY в положение ON. Сравните новый план запроса со старым до обновления статистики, для того чтобы определить изменения в нем (иногда требуется довольно длительное время для построения плана). Сравнивая планы, можно избежать повторного выполнения запроса только для того, чтобы убедиться, что производительность его выполнения идентична предыдущему выполнению этого запроса. Если статистика изменилась, то выполните запрос, чтобы определить, увеличилась ли производительность и насколько.
Шаг 2. Упростить команду SELECT. Перед добавлением индексов или переписыванием плана выполнения следует попытаться упростить запрос. Задача состоит в том, чтобы сделать выражение SELECT как можно проще, сократив по мере возможности число переменных в нем. Упростив запрос, скомпилируйте команду, чтобы посмотреть план запроса. Сравните новый план запроса со старым. Определите, увеличилась ли производительность запроса, выполнив его.
Для того чтобы упростить SELECT, необходимо:
Исключение ненужных предикатов и предложений. Обычно в команду SELECT включают предложений больше, чем это необходимо на самом деле. Так делается для того, чтобы гарантировать корректность ответа, или из-за плохого понимания синтаксиса SQL. До попытки настроить запрос проектировщик базы данных должен удалить все ненужные предложения и предикаты.
Примерами предложений, которые обычно включаются в запрос, но не являются необходимыми, являются следующие:
WHERE DEPT_NO = 10 AND DEPT_NAME = 'PERATIONS'.
Расстановка скобок в арифметических и логических выражениях. Синтаксис SQL SQLBase включает специальные правила предшествования для оценки арифметических и логических выражений. Однако достаточно просто сделать ошибку при применении правил предшествования. Следовательно, мы рекомендуем вам расставлять скобки в этих выражениях для явного определения предшествования в выполнении операций. Вы можете подумать, что оптимизатор оценивает выражения одним способом, а в действительности он поступает по-другому.
Преобразование связанных переменных в константы. Связанные переменные обычно используются, когда компилируется команда SQL. Часто желательно использовать хранимые команды для того, чтобы исключить перекомпиляцию утверждения SQL, которое будет выполняться много раз. Эти хранимые команды являются скомпилированными, и их планы выполнения сохраняются в системном каталоге вместе с исходным текстом. Приложения тоже выполняют предкомпиляцию для многократно используемых команд выборки. В этих ситуациях связанные переменные используются для передачи некоторых значений в команду во время ее выполнения.
Природа индексной структуры на основе В-дерева такова, что она может работать с символом подстановки, если он не стоит в начальной позиции строки. Ясно, что оптимизатор не будет использовать индекс, если символ постановки будет стоять на первой позиции (как при использовании связанной переменной в предикате LIKE). В этих случаях будет применено сканирование таблицы.
Преобразовывайте связанные переменные в предикате LIKE в константы для увеличения производительности такого запроса.
Шаг 3. Пересмотреть план запроса. Выполните запрос так, чтобы посмотреть его план. Вы должны хорошо понимать план запроса, чтобы использовать его. Несколько элементов этого плана требуют особого внимания.
Шаг 4. Локализовать узкие места. Запрос, который выполняется медленно, может содержать много предложений и предикатов. Если это так, нужно определить, какие предложения или предикаты приводят к плохой производительности. Если удалить одно или два предложения или предиката, производительность выполнения запроса возрастает значительно. Эти предложения являются критическими параметрами выполнения запроса.
Можно поэкспериментировать с запросом, поочередно удаляя из него предложения или предикаты до тех пор, пока не будет достигнут подходящий уровень производительности.Локализуйте критические предложения и предикаты.
Примеры:
Фактор селективности в случае нескольких предикатов
Когда несколько предикатов используются для выборки строк из одной таблицы, оптимизатор следует некоторым фиксированным правилам, которые комбинируют фактор селективности каждого из них в некоторый суммарный. Первое правило не зависит от того, как много предикатов рассматривается, когда вычисляется итоговый фактор селективности для предикатов, содержащих операторы равенства и неравенства. Это следующие правила.Пример. Пусть задан предикат
EMPLOYEE_NO = 45 AND DEPT = 50 AND SALARY > 25000.
Предположим, что индекс определен для составного ключа, содержащего указанные колонки в следующем порядке: EMPLOYEE_NO, DEPT, SALARY. Комбинация факторов селективности для колонки EMPLOYEE_NOи для колонки DEPT, которые появляются в колонке DISTINCTCOUNT строки DEPT таблицы системного каталога SYSKEYS, используется оптимизатором для оценки числа строк, которые будут возвращены по запросу. Действие предиката неравенства для колонки SALARY игнорируется.
SALARY > 25000 AND DEPT = 50 AND YEARS_SERVICE > 3.
Предположим, что индекс определен для составного ключа, содержащего указанные колонки в следующем порядке SALARY, DEPT, YEARS_SERVICE. Оптимизатор определяет фактор селективности, просматривая корневую страницу индекса для определения числа строк таблицы, для которых выполняется предикат "Зарплата больше 25000". Это значение и становится фактором селективности для всей группы предикатов. Оставшиеся предикаты игнорируются.
Таким образом, на первом шаге своей работы оптимизатор СУБД SQLBase, подготавливая для выполнения команду SQL, строит список вариантов путей доступа, которые могли бы удовлетворить запросу (планы выполнения). Поскольку оптимизатор основан на вычислении стоимости, используется статистика базы данных как основа выполнения оценок того, какая работа требуется для реализации каждого возможного плана выполнения.
Далее оптимизатор запросов строит группу альтернативных планов выполнения, каждый план выполнения оценивается вычислением стоимости так, чтобы наиболее эффективный план мог быть выбран. При этом оцениваются два компонента общей стоимости плана выполнения - требования по вводу/выводу и требования по времени процессора. Выбирается план с наименьшим значением вычисленной стоимости.
Фактор селективности в случае одного предиката
Определение фактора селективности для одного предиката, такого как EMPLOYEE_NO=65, зависит от того, какой оператор используется в предикате. Оператор влияет на фактор селективности, так как он определяет взаимосвязь между строками, которые удовлетворяют предикату и другим операндам.Чем большее число строк отбрасывает оператор предиката при выборке (ограничивает), тем меньше фактор селективности предиката. Наиболее трудоемким для выполнения оператором (по числу операций ввода-вывода) является оператор равенства, поскольку только одно значение колонки может удовлетворить предикату. В этом случае фактор селективности просто обратно пропорционален кардинальности колонки, которая сохраняется в колонке DISTINCTCOUNT таблицы SYSADM.SYSINDEXES для этой колонки (как индексируемого ключа).
Однако непросто вычислить фактор селективности для операторов неравенства. Рассмотрим следующие два предиката:
ORDER_DATE > JAN-01-1900 ORDER_DATE > SYSDATE -1 DAY
Очевидно, что первый предикат, как можно было бы ожидать, возвратит гораздо больше строк, чем второй, когда будет применен к таблице ORDER.
Как оптимизатор может определить это? Оказывается, что оптимизатор вычисляет фактор селективности посредством доступа к верхнему уровню индекса той индексной структуры, которая содержит колонку запроса (ORDER_DATE). Затем он оценивает число строк, которое удовлетворяет предикату, экстраполируя пропорцию индексных ключей на этом уровне индекса. Этот метод, называемый сканирование B-дерева (B-tree scan), позволяет оптимизатору сделать достаточно точную оценку результатов применения предикатов неравенства.
Другой фактор, который играет роль в определении фактора селективности одного предиката неравенства, есть ответ на вопрос, будет ли сравниваться колонка с константой или связанной переменной? Это некритично для предиката равенства потому, что оптимизатор может вычислить фактор селективности исходя из значения DISTINCTCOUNT в предположении равновероятного распределения значений колонки по строкам таблицы.
Такое предположение позволяет оптимизатору быть нечувствительным к действительным значениям операнда с другой стороны знака равенства. Однако для использования метода сканирования В-дерева оптимизатор должен быть способным найти значение другого операнда. Когда операнд является связанной переменной, оптимизатор должен опуститься назад для проверки предположения, что в действительности трудно закодировать.
Нижеследующая таблица 16.1 суммирует определения фактора селективности для одного предиката, в зависимости от операции и типа второго операнда.
| = | 1/card | 1/card |
| !=,<> | 1-1/card | 1/3 |
| > | Сканирование индекса | 1/3 |
| !> | Сканирование индекса | 1/3 |
| < | Сканирование индекса | 1/3 |
| >= | Сканирование индекса | 1/3 |
| <= | Сканирование индекса | 1/3 |
| Between | Сканирование индекса | 1/3 |
| Null | - | Не используется |
| Exists | Преобразование | Преобразование |
| Like | Сканирование индекса | Не определен |
| In | Преобразование | Преобразование |
Фактор селективности
Фактор селективности является статистическим показателем, который вычисляется оптимизатором для предикатов, используемых реляционной операцией выборки. В дополнение, фактор селективности используется оптимизатором для определения того, является ли путь доступа через индекс более эффективным, чем сканирование таблицы. Следовательно, фактор селективности вычисляется только для тех предикатов, которые содержат индексируемые атрибуты.Фактор селективности оценивает число строк, которые возвращаются при применении предикатов выборки на таблицу известного размера. Это является важным моментом, когда оптимизатор оценивает использование индекса при построении плана выполнения. Индекс будет более эффективным, чем сканирование таблицы, только если высота индекса, умноженная на фактор селективности, умноженные на число строк в таблице, будет меньше, чем число физических страниц базы данных, занятых таблицей.
Другими словами, если большинство строк таблицы должны быть выбраны, использование индекса повлечет за собой увеличение числа операций ввода/вывода за счет чтения индекса. При этом именно фактор селективности проявляется виртуально в стоимости ввода/вывода, связанной с операцией доступа к индексу, которая используется оптимизатором.
Численно фактор селективности представляет вероятность, которая изменяется от 0 до 1. Умножение числа строк в таблице на фактор селективности для связанного с ним предиката будет давать ожидаемое число строк для операции выборки, при предположении, что значения колонок таблицы равномерно распределены по строкам.
Использование оптимизатора для оптимизации выполнения запросов
При создании физической модели реляционной базы данных мы рассмотрели общие принципы и эвристические правила создания внутренней схемы, которая обеспечивает хорошие характеристики производительности для большинства SQL запросов. Однако методики физического проектирования не гарантируют того, что некоторые запросы будут иметь хорошие характеристики производительности без дальнейшей настройки.Существует много вариантов увеличения производительности запросов. Основной идеей для выбора самого подходящего является построение запроса таким образом, чтобы оптимизатор запросов СУБД вычислил оптимальные по стоимости пути доступа для его выполнения.
Так, например, при работе с оптимизатором СУБД SQLBase для увеличения производительности конкретной команды SELECT, проектировщик базы данных или администратор баз данных выполняет следующие действия:
Обновление статистики. Статистика в СУБД SQLBase поддерживается независимо как для таблиц, так и для индексов. Оптимизатор использует эти статистики для вычисления стоимости различных путей доступа. Следовательно, первым аспектом работы с оптимизатором запросов, для улучшения производительности данного запроса, является гарантия того, что эти статистики корректны и обновляемы.
Оптимальное множество индексов. Другим аспектом работы с оптимизатором запросов является добавление индексов для увеличения скорости выполнения секций и соединений, оценки сортировки в предложениях GROUP BY и ORDER BY. Если утверждение SELECT выполняется медленно, то это, вероятно, либо соединение, сортировка, либо чтение большой таблицы. Индексы могут увеличить производительность всех этих операций.
Общая стратегия индексирования состоит в создании индексов для всех первичных и внешних ключей. Это так, потому что в большинстве систем существуют колонки, которые извлекаются гораздо чаще в предикатах предложений WHERE, GROUP BY, ORDER BY.
Этот первоначальный набор индексов базы данных обеспечивает индексацию для выполнения селекции и исключений сортировок первичных и внешних ключей. Следовательно, часто соединения являются наиболее критическим временным аспектом конкретного запроса. Самый быстрый алгоритм соединения для больших таблиц есть объединение индексов. Первоначальный набор индексов гарантирует, что путь доступа с объединением индексов доступен для оптимизатора запросов, когда колонка соединения является первичным или внешним ключом. Для всех других соединений оптимизатор ограничивается более медленными алгоритмами соединения, хэш-соединением или одним из алгоритмов соединения в цикле. Однако для большинства утверждений SELECT пути доступа, допустимые для оптимизатора на первоначальном наборе индексов, обеспечивают адекватную производительность.
С другой стороны, первоначальный набор индексов может не удовлетворять требованиям по производительности для всех запросов. Например, некоторые запросы, содержащие колонки соединения, не являющиеся ни первичным, ни внешним ключами, могут выполняться медленно. Для таких запросов, чтобы они удовлетворяли критериям производительности, необходимо добавить дополнительные индексы. Однако нецелесообразно создавать один или более индексов для каждого оператора выборки, поскольку:
Следовательно, общая цель проектирования состоит в том, чтобы создать набор индексов, который отвечает требованиям производительности для всех транзакций к базе данных. Это и есть оптимальный набор индексов.
Переписывание плана выполнения запроса, выбранного оптимизатором. В СУБД SQLBase такая процедура выполняется с помощью настройки команды SELECT. Она может быть применена в при использовании других реляционных СУБД.
Однако в некоторых СУБД, например СУБД Oracle, проектировщик базы данных может явно влиять на выбор тех или иных вариантов улучшения скорости выполнения запросов.
На уровне экземпляра режим работы оптимизатора задается администратором базы данных. На уровне сессии используется команда вида
ALTER SESSION SET OPTIMIZER_GOAL = <режим>;
В качестве режима может быть задано одно из следующих значений:
| ROWID | Использование идентификатора |
| CLUSTER | Сканирование ключа кластера |
| HASH | Сканирование хэш-индекса |
| INDEX | Сканирование индекса |
| INDEX_ASC | Сканирование индекса в порядке возрастания |
| INDEX_DECS | Сканирование индекса в порядке убывания |
| AND_FFS | Быстрое полное сканирование индекса |
| AND_EQUAL | Использование нескольких индексов со слиянием результатов |
| FULL | Полное сканирование таблицы |
Более подробно об использовании оптимизатора запросов СУБД Oracle можно прочитать в рекомендованной к лекции литературе.
Для управления оптимизатором СУБД Oracle используются специальные подсказки, которые записываются в SQL-командах. Такие подсказки влияют на выбор конкретного способа обращения к данным. Пример ниже содержит подсказку оптимизатора для использования индекса (в предположении, что таблица имеет один индекс):
Пример
SELECT /* + index */ EMPLOYEE_NO, DEPT, SALARY FROM EMPLOYEE WHERE EMPLOYEE_NO = 65;
Подсказка является частью комментария, следующего за ключевым словом команды, и отмечается символом "+".
Для эффективного переписывания плана выполнения запроса необходимо в течение некоторого времени накопить знания о работе СУБД с базой данных, в частности, определить список проблемных запросов и их характеристик. При решении задач оптимизации проблемных запросов нужно следовать следующим рекомендациям:
Одним из важных вопросов при работе с оптимизатором запросов является выбор режима его работы (если такая возможность предоставляется СУБД). Так, для оптимизатора СУБД Oracle режим оптимизации может быть задан на уровне экземпляра базы данных, на уровне сессии или SQL-команды.
Реализация оптимизатора SQLBase
На примере оптимизатора СУБД SQLBase рассмотрим основные принципы реализации оптимизаторов обработки запросов, основанных на вычислении стоимости, и покажем, как использовать эти принципы в случае ручной настройки запросов.Статистика базы данных
Когда оптимизатор запросов SQLBase осуществляет выбор пути доступа, он использует статистику базы данных для оценки стоимости, связанной с каждым вариантом пути доступа, т.е. планом выполнения. Эта статистика, которая сохраняется в системном каталоге SQLBase, связана с различными таблицами и индексами, содержащимися в базе данных. Часть статистических данных поддерживается динамически, т.е. сервер SQLBase сам поддерживает ее обновление во время обычных операций сервера. Однако большая часть статистической информации поддерживается статически, т.е. она вычисляется и сохраняется, когда происходят определенные события.Событие, которое обычно приводит к обновлению статистики базы данных, есть выполнение команды SQL UPDATE STATISTIC. Эта команда проверяет таблицы и индексы базы данных, вычисляет требуемые статистические показатели и затем сохраняет их в соответствующих таблицах системного каталога. Статистика также создается для индексов или таблиц при их первоначальном создании. Если никаких строк не вставляется в таблицы и индексы до момента обновления статистики по команде SQL UPDATE STATISTIC, то статистические показатели устанавливаются к значениям по умолчанию.
Как правило, статистика базы данных может быть обновлена администратором базы данных. После выполнения обновления пути доступа выбираются оптимизатором на основе вычисления стоимости по статистике, сохраненной в системном каталоге. В этом случае системный администратор может влиять на выбор путей доступа оптимизатором, исходя не из текущего содержания базы данных, а из ее предполагаемого содержания в будущем. Для того, чтобы точно вычислить и сохранить эту статистику, системный администратор должен знать, что эта статистика означает.
Статистика базы данных, которая поддерживается динамически, используется оптимизатором независимо от того, было ли сделано обновление статистики в системном каталоге. Она основывается на сборе статистики в результате действий пользователей над таблицами и индексами. Однако если статистика была обновлена в системном каталоге, то при выборе решений оптимизатор будет отдавать предпочтение обновленным статистическим показателям.
Статистика индексов
Статистика, связанная с индексами таблицы, также поддерживается в двух отдельных таблицах системного каталога. Все колонки (за исключением одной - HEIGTH - в таблице SYSINDEXES) поддерживаются статически и заполняются, когда выполняется команда UPDATE STАTISTICS или создается индекс.В таблице SYSADM.SYSINDEXES статистическая информация поддерживается в следующих колонках:
Это число необходимо для того, чтобы поддерживать все входы индекса как данные с переменной длиной. Это поле равно нулю для хэш-индексов.
В таблице SYSADM.SYSKEYS поддерживается следующая статистическая информация.
Простейший пример есть колонка Пол (SEX_CODE), которая имеет кардинальность 2. Рассмотрим следующий индекс:
CREATE INDEX XNKSALS ON EMPLOYEE (DEPT, SALARY, YEARS_SERVICE);
Таблица EMPLOYEE содержит 250 строк, по одному для каждого служащего компании. Кардинальность множества значений колонок есть:
При этих заданных условиях строки таблицы, которые описывают эти индексируемые колонки, имеют следующие значения DISTICTCOUNT:
Статистика таблиц
Статистика, связанная с таблицами базы данных, поддерживается в двух различных таблицах системного каталога, каждая из которых описывается ниже. Все колонки, не указанные специально как динамически поддерживаемые, являются статическими и заполняются при выполнении команд UPDATE STATISTIC или CREATE.В таблице системного каталога SYSADM.SYSTABLES для сохранения статистики используются следующие колонки:
В таблице системного каталога SYSADM.SYSCOLUMNS поддерживается следующая статистическая информация:
Базы данных: Разработка - Управление - Excel
- Базы данных
- Разработка баз данных
- СУБД и базы данных
- Управление базами данных
- Классика баз данных
- Софт для создания базы данных
- SQL
- Access
- FoxProо
- Расширенная оптимизация подзапросов в Oracle
- Informix
- Линтер
- Postgres
- СУБД DB2
- InterBase
- Excel
- Таблицы Excel
- Справка Excel
- Программирование в Excel
- Деньги в Excel
- Задачи Excel