бд полный курс. Информация, данные, информационные системы Информация как социальный ресурс
 Скачать 1.56 Mb.
|
|
Рис. 3.9. Декомпозиция этапа проектирования - создание первой итерации физической модели базы данных: внутренняя схема  Рис. 3.10. Декомпозиция работы по индексированию базовой таблицы Следует еще раз отметить субъективный характер принятия решений проектировщиком базы данных из-за отсутствия во многих случаях точных сведений о характере выполнения транзакций в системе. Большинство решений принимается на основе эвристических правил и личного опыта проектировщика. Метод работы проектировщика базы данных сводится к изменению структуры объектов базы данных на основе перебора возможных способов повышения производительности, их сопоставления и обоснованного выбора подходящего решения. На этом мы заканчиваем рассмотрение задач проектировщика базы данных по созданию физической модели реляционной базы данных с учетом влияния транзакций. Главная цель этого этапа - видоизменить последовательность команд SQL для создания объектов хранения данных с учетом влияния транзакций на производительность базы данных. Краткое рассмотрение задач создания серверного кода и подготовки скрипта Профессиональная задача проектирования баз данных - разработка серверного кода базы данных - возникает, как правило, в многопользовательской вычислительной среде. В многопользовательских системах пользователи совместно используют вычислительные ресурсы, в частности ресурсы дисковой памяти и оперативной памяти процессора. Вычислительные ресурсы могут быть сконцентрированы в одном месте (централизованные вычисления) или быть рассредоточенными в различных узлах, объединенных в компьютерную сеть (распределенные вычисления). СУБД в любом случае призвана координировать и осуществлять доступ пользователей к базам данных и их объектам. Большинство современных СУБД поддерживают концепцию клиент-серверной технологии для распределенных вычислений. Это означает, что существуют концентраторы вычислений (называемые серверами), на которых выполняется наибольший объем вычислений с данными (серверы баз данных), и машины пользователей (клиенты), на которых выполняются приложения пользователей. Приложения формируют запросы в форме команд SQL к базам данных, отправляют их серверам баз данных, получают запрашиваемые данные и обрабатывают их. В клиент-серверной вычислительной среде приложение может взаимодействовать с сервером баз данных по другой схеме: когда приложение отправляет запрос, этот запрос обрабатывается на сервере, а приложению возвращается готовый результат. Работа приложения по второй схеме основывается на использовании так называемого серверного кода (server-side code) - любого кода, выполняемого компьютером, на котором установлена СУБД. Ядро СУБД выполняет этот код в базе данных и возвращает приложению только результат. Например, это может быть несколько колонок строки или вычисленное значение. Использование серверного кода может значительно сократить объем сетевого трафика и тем самым увеличить производительность базы данных в целом. Однако СУБД должна иметь встроенные средства для распознавания и обработки такого кода. Многие фирмы - производители промышленных СУБД, в том числе и Oracle, предлагают процедурные расширения SQL, с помощью которых можно выполнять построчную обработку данных, использовать циклы, сложные вычисления и операции управления данными. PL/SQL является таким расширением SQL в СУБД Oracle 9i. Он позволяет создавать серверный код в виде объектов реляционной базы данных, таких, как хранимые процедуры, функции, пакеты и триггеры. Проектировщик реляционной базы данных, который использует для создания базы данных СУБД Oracle, имеет возможность рассмотреть создания таких объектов с целью сокращения сетевого трафика или принять решение о переносе определенного объема обработки на сервер, особенно в тех случаях, когда эта обработка выполняется очень интенсивно. Например, несколько строк разных таблиц проверяются перед вставкой новой строки. Таким образом, разработка серверного кода сводится к решению следующих подзадач: принятие решения и создание хранимых процедур; принятие решения и создание функций; принятие решения и создание пакетов; принятие решения и создание триггеров. Задача проектирования базы данных - подготовка инсталляционного скрипта для создания базы данных - в определенной степени завершающая для самостоятельной работы проектировщика базы данных. Такой скрипт - это один из главных результатов его работы. Проектировщик базы данных, выполнив предыдущие задачи, фактически выполнил свою основную работу над созданием скрипта для базы данных. Если работа по проектированию базы данных закончена, зачем проектировщику еще что-то делать, кроме того как проанализировать и проверить проделанную работу, отредактировать окончательный вариант скрипта и создать физическую базу данных? Принято считать, что задача создания базы данных, так же как и управление базой данных, является задачей администратора базы данных. Значит, можно задокументировать проделанную работу и передать ее администратору базы данных. Однако процесс проектирования физической модели базы данных не закончен. Из нашего рассмотрения выпали следующие вопросы: требования по обеспечению потенциальных пользователей к базе данных и ее объектам, так называемые требования безопасности базы данных; требования к размещению и хранению объектов базы данных на физических носителях в рамках операционной системы, т.е. привязка объектов базы данных к файлам операционной системы. Однако одним из главных результатов проектирования базы данных является создание физической базы данных на основе разработанного в процессе проектирования инсталляционного скрипта. Поэтому проектировщик базы данных должен вместе с администратором базы данных рассмотреть вышеуказанные задачи и подготовить такой инсталляционный скрипт для создания базы, а не передавать эту работу администратору базы данных, хотя на практике последнее часто происходит. С другой стороны, проектировщик базы данных в организации зачастую выступает в качестве администратора базы данных. Это тоже одна из важных причин рассмотрения решения этих вопросов в рамках этого курса. Таким образом, задача создания скрипта базы данных состоит из решения крупных подзадач: создание пользователей, их идентификация и назначение им привилегий; привязка разработанных объектов реляционной базы данных к параметрам физического хранения базы данных с помощью создания специальных объектов базы данных; создание инсталляционного скрипта; документирование базы данных. В этой лекции мы рассмотрели, в чем состоит сложный процесс проектирования базы данных, принципы построения бизнес-модели проектирования базы данных и основные фрагменты типовой бизнес-модели. Автор надеется, что предложенная бизнес-модель будет использована, достроена и доработана слушателями в процессе их самостоятельной работы. Изученный материал является основой планирования проектирования базы данных. Проектировщик всегда должен иметь гибкий план для организации процесса своей работы. Лекция 4: Реляционная модель данных Информация, данные, информационные системы Понятие отношения Реляционная модель данных была предложена Е.Ф. Коддом в 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. Использование понятия декартового произведения для определения отношения в реляционной модели данных делает модель конструктивной. На математическом языке это означает, что все остальные понятия модели определяются в рамках строго математического построения на базе декартового произведения.Табличная форма представления отношения была введена в целях популяризации модели среди неподготовленных пользователей баз данных. Трактовка реляционной теории на уровне таблиц скрывает ряд определений, важных для понимания как теории реляционных баз данных, так и языка манипулирования данными, моментов. Во-первых, атрибуты разных отношений могут быть определены на одном домене, так же как и атрибуты одного отношения. Это очень важное обстоятельство, позволяющее устанавливать связи по значению между отношениями. Во-вторых, множество математически по своему определению не может иметь совпадающих элементов, и, следовательно, кортежи в отношении можно различить лишь по значению их компонент. Это тоже очень важное для модели обстоятельство: никакие два кортежа не могут иметь полностью совпадающих компонент. Таким образом, в реляционной модели полностью исключается дублирование данных о сущностях реального мира! В-третьих, заметим, что схема отношения также есть множество, что позволяет работать с ними с помощью теоретико-множественных операций. Это является важным моментом для построения теории проектирования реляционных схем баз данных. Существует определенное различие между математическим определением отношения и действительным хранением отношений в памяти компьютера. По определению, отношение не может иметь два идентичных кортежа. Однако СУБД, поддерживающие реляционную модель данных, хранят отношения в файлах операционной системы компьютера. Размещение отношений в файлах операционной системы допускает хранение идентичных кортежей. Если не используется специальная техника (контроль целостности по первичному ключу ), то обычно большинство промышленных СУБД допускают хранение двух идентичных кортежей в базе данных. С математической точки зрения однородность реляционной модели, о которой упоминалось выше, состоит в том, что схема отношения является постоянной, иначе говоря, каждая строка таблицы имеет один и тот же формат. С другой стороны, предполагается, что каждая строка таблицы представляет некую сущность реального мира или связь между ними. Обладают ли сущности реального мира такой однородной структурой, является вопросом, на который должен ответить аналитик или эксперт-пользователь. Решение о пригодности использования реляционной модели для моделирования данных конкретной предметной области решается руководителем ИТ-проекта и аналитиками. ормы представления отношений Как мы уже упоминали выше, отношения можно представлять в виде таблиц. Но в табличном представлении сложно показывать некоторые свойства отношений. Например, неоднозначность трактовки домена колонки. Поэтому предпринимаются попытки строить более четкие схемы описания отношений в реляционных базах данных. Ниже представлен фрагмент такого описания в виде примера схемы базы данных "КАДРЫ": СХЕМА "ОТДЕЛ_КАДРОВ" ДОМЕН Т_Табельный_номер ТИП целое ДОМЕН Т_ФИО ТИП символьное ДОМЕН Т_Зарплата ТИП десятичное с фиксированной точкой ..... ОТНОШЕНИЕ Служащий ( Табельный-номер / КЛЮЧ / ДОМЕН = Т_Табельный-номер, ФИО / ДОМЕН = Т_ФИО, .... ) .... КОНЕЦ ОПИСАНИЯ СХЕМЫ. Подобное описание не прижилось среди проектировщиков баз данных. На практике прибегают к такому описанию крайне редко. Для дальнейшего изложения нам понадобится одно из самых важных понятий обработки данных - понятие ключа. Ключом или ключевым полем называется уникальное значение, которое позволяет тем или иным способом идентифицировать сущность или часть сущности предметной области, т.е. ключ - это значение некоторого атрибута или атрибутов в кортеже отношения, который представляет экземпляр сущности в реляционной модели данных. Внимание! На данном этапе изложения мы не проводим особого различия между понятиями "ключ отношения" и "ключ сущности" предметной области, хотя далее мы будем эти ключи различать. Заметим, что в определении ключа не требуется однозначной идентификации сущности предметной области базы данных. Ключ отношения - это не уникальный идентификатор сущности предметной области. Однако последний есть возможный кандидат на ключ отношения, иначе говорят, возможный ключ. Принято различать первичные ключи и частичные ключи. Математически первичным ключом отношения R со схемой r является подмножество сужения декартового произведения, которое позволяет однозначно идентифицировать кортеж. Если первичный ключ содержит несколько атрибутов, то он называется составным ключом, в противном случае - атомарным. Частичным ключом называется атрибут составного ключа, если он однозначно определяет совокупность неключевых атрибутов отношения. Атрибут кортежа, который является первичным ключом другого отношения, называется внешним (иногда посторонним) ключом. Из определения отношения следует следующее важное свойство реляционной модели данных: каждое отношение должно иметь первичный ключ. Отсутствие первичного ключа в отношении может привести к приобретению кортежей, которые не определены текущим состоянием предметной области, или к потере уже существующих кортежей при выполнении теоретико-множественных операций. Причина подобных казусов лежит в механизме построения декартова произведения. Заметим, что ключ в контексте модели предметной области базы данных всегда отражает ту или иную степень связи между атрибутами сущностей предметной области, т.е. семантически ключ есть средство моделирования связей в модели. Пример: рассмотрим предложение "Гражданин Иванов проживал в городе Москве 10 лет". Возможными атрибутами в отношении Место_жительства являются фамилия гражданина, название города проживания и время проживания. Фамилия гражданина может выступать в качестве первичного ключа этого отношения, так как личность однозначно определяет время ее проживания в конкретном городе. Таким образом, в этом отношении моделируется связь "проживал" между атрибутами "фамилия" и "город". Отношения в реляционной модели данных, как правило, представляются с помощью функциональной формы записи (так как мы записываем функции нескольких переменных в математическом анализе), при этом атрибуты первичного ключа подчеркиваются: ИМЯ_ОТНОШЕНИЯ (Атрибуты первичного ключа, неключевые атрибуты). Пример. Представление связи отношением. Представим связь между личностью и местом ее проживания через отношение ПРОЖИВАЕТ (Кл. личность, Кл. населенный_пункт, время) Описание личности: ЛИЧНОСТЬ (Кл. личность, ФИО, возраст, пол) Описание населенного пункта: НАСЕЛЕННЫЙ_ПУНКТ (Кл.населенный_пункт, география, население) Однако наибольшее распространение получило представление отношений в виде графических диаграмм, например ER-диаграмм, о которых мы говорили в первой лекции. Преимуществами такого представления являются наглядность диаграмм и возможность их построения в ряде CASE-средств проектирования баз данных. Обычно CASE-средства позволяют поддерживать несколько уровней представления отношений. Так, например, ErWin поддерживает уровень логической и физической моделей базы данных. Отметим, что представление фрагментов реального мира через отношения даже в рамках одной модели данных не характеризуется единственностью. Например, зададимся вопросом: "Что есть цвет автомобиля? Связь, объект или атрибут?" Если за объект принять автомобиль, то цвет может выступать в качестве атрибута автомобиля. Если рассматривать зависимость отражательной способности покрытия автомобиля от его цвета, то цвет можно считать объектом. Если рассматривать взаимосвязь между цветом модели автомобиля и ее номером, то цвет можно считать связью. В любом случае при представлении какого-либо качества реального мира в модели следует четко понимать, какие запросы в рамках создаваемой модели данных должны быть разрешимыми. Рассмотрим отношение КРАСНЫЙ (модель). При использовании такого отношения на вопрос: "Является ли модель X красного цвета?" может быть получен ответ: "Да" или "Нет". Вопрос: "Какой цвет у модели Х?" ответа не имеет, так как в отношении отсутствует атрибут "цвет". В итоге сформулируем основные свойства реляционной модели данных, которые следуют из понятия отношения как множества. Все кортежи одного отношения должны иметь одно и то же количество атрибутов. Значение каждого из атрибутов должно принадлежать некоторому определенному домену. Каждое отношение должно иметь первичный ключ. Никакие два кортежа не могут иметь полностью совпадающих наборов значений. Каждое значение атрибутов должно быть атомарными, т.е. не должно иметь внутренней структуры и содержать в качестве компонента другое отношение. Реляционная модель данных должна быть непротиворечивой, в частности должен выполняться 1) принцип ссылочной целостности - связи между отношениями должны быть замкнутыми, 2) значения колонок должны принадлежать одному и тому же определенному для них домену. Порядок следования кортежей в отношении не имеет значения. Порядок есть в большей степени свойство хранения данных, чем свойство непосредственно самой реляционной модели данных. |