andrey

Путь к Файлу: /Информатика / 2-kurs / Теория_Базы_данных.pdf

Ознакомиться или скачать весь учебный материал данного пользователя
Скачиваний:   56
Пользователь:   andrey
Добавлен:   05.01.2015
Размер:   328.4 КБ
СКАЧАТЬ

Наверх страницы

Содержимое файла:

ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ База данных (БД) – именованная совокупность данных, отображающих состояние объектов и их отношения в рассматриваемой предметной области. К базам данных предъявляются следующие требования: модельность – БД должна моделировать некоторую часть объектов реального мира; актуальность – БД должна отражать текущее состояние объектов реального мира и динамически обновляться в соответствии с изменениями в состоянии объектов; непротиворечивость – данные в БД не должны противоречить друг другу и выбранной модели предметной области. целостность – БД должна по возможности наиболее полно моделировать объекты реального мира в рамках выбранной предметной области; интегрированность – данные, хранящиеся в БД, должны быть направлены на решение общих задач, поставленных при ее разработке; надежность – данные должны быть защищены от потери либо искажения. Система управления базами данных (СУБД) – это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. К языковым средствам относятся средства информационно-логического моделирования баз данных, языки описания данных, составления запросов, управления данными, языки программирования баз данных. Разработчики баз данных решают задачи моделирования баз данных, проектирования и разработки структуры будущей БД, создания и модификации структуры базы данных, разработка и реализация программных средств для работы с данными, пользовательских интерфейсов, автоматизированных рабочих мест и т.д. Ведение БД относится к компетенции администраторов баз данных, решающих задачи управления учетными записями пользователей БД, их идентификации и авторизации, разграничения прав доступа к данным, управления дисковым пространством, обеспечения надежности хранения данных, создания резервных копий данных, восстановления БД в случае сбоев в работе аппаратных или программных средств и т.д. Пользователи БД имеют возможность просмотра данных, выборки данных в соответствии с критериями отбора данных, ввода новых и обновления (актуализации) имеющихся данных, анализа данных и составления различных итоговых отчетов и т.д. Обеспечение коллективного доступа многих пользователей к БД подразумевает поддержание целостности и непротиворечивости данных при одновременном выполнении задач, просмотра, выборки, редактирования данных, а также администрирования базы данных. Программные средства, с которыми работают пользователи при решении различных задач, называются приложениями. Именно СУБД призвана обеспечить параллельную и независимую работу множества приложений с единой базой данных. СУБД, как пакет программ, обычно имеет отдельные компоненты для определения и модификации структуры БД, администрирования БД, создания экранных форм (интерфейса конечного пользователя) для просмотра, ввода и редактирования данных, генерации отчетов, обмена данными с другими программами, создания приложений и др. Эффективность конкретной СУБД определяется наличием и удобством использования средств выполнения этих операций. АРХИТЕКТУРА БАЗЫ ДАННЫХ Информация об определенной предметной области представлена в базе данных моделями нескольких уровней. По числу уровней в архитектуре различают одноуровневые, двухуровневые, трехуровневые системы. На различных уровнях архитектуры СУБД поддерживается разный уровень абстракции данных. В настоящее время наиболее распространенной является предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, концептуальный, внутренний и внешний. «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров. представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически, концептуальный уровень отражает обобщенную логическую модель предметной области, для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов предметной области. Концептуальная модель является моделью логического уровня и не зависит от особенностей используемой СУБД. Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных. страничных структурах, расположенных на внешних носителях информации. Физическое представление БД относится к внутреннему уровню. Он описывает способы организации данных на внешних носителях информации (в виде файловых или страничных структур) и предназначен для достижения оптимальной производительности и эффективности использования ресурсов вычислительной системы. Описание физической структуры БД называется схемой хранения, а соответствующий этап проектирования БД – физическим проектированием. Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования. Во время фазы логического моделирования разработчик собирает требования к разрабатываемой БД, составляет описание предметной области и разрабатывает модель, не зависящую от конкретной СУБД. Во время фазы физического моделирования разработчик создает модель, оптимизированную для СУБД и конкретных приложений пользователей. В настоящее время внутренний уровень практически полностью обеспечивается СУБД. Основной акцент при проектировании БД переносится на создание модели концептуального уровня. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных, и реорганизации механизма доступа к физическим данным. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с базой данных. КЛАССИФИКАЦИЯ БАЗ ДАННЫХ По типу хранимой информации базы данных делятся на документальные, лексикографические и фактографические. К документальным базам можно отнести библиографические, реферативные и полнотекстовые. Библиографические базы данных содержат только выходные данные печатных изданий (название, авторы, год издания, издательство, количество страниц и т.д.). Традиционным аналогом такой базы можно считать библиотечный каталог. Реферативные базы данных, помимо выходных данных, содержат краткое содержание (реферат) описываемой публикации. Полнотекстовые базы данных включают в себя полный текст документа. К ним относятся, например, справочные юридические системы, поскольку для работы с законами и нормативными актами необходим полный текст документа, а не только его выходные данные. Лексикографическими базами данных считаются различные словари (толковые словари, многоязычные словари, классификаторы и т.п.). Большая часть химических баз данных являются фактографическими. Базы данных можно различать по степени структурированности информации. К неструктурированным следует отнести базы данных, организованные в виде семантических сетей. Частично структурированными являются гипертекстовые документы. Структурированные базы данных, в свою очередь, по типу используемой модели данных делятся на иерархические, сетевые, объектно-ориентированные и реляционные. Первые две модели являются теоретико-графовыми, т.е. отражают совокупность объектов Иерархическая модель наилучшим образом подходит для описания таких предметных областей, в которых имеется естественная иерархия объектов, например, сборка сложного изделия из комплектующих. В то же время она обладает избыточностью и недостаточной гибкостью. Сетевая модель частично устраняет недостатки предшественницы, но за счет существенного усложнения. В настоящее время большинство коммерческих СУБД основано на реляционной модели данных. Объектно-ориентированные базы данных считаются перспективными, в первую очередь благодаря встроенным средствам моделирования взаимодействия объектов, однако коммерческого признания пока не получили. Существуют также и других классифицирующие признаки, например, характер организации хранения данных. По этому признаку можно отличить персональные, интегрированные и распределенные базы данных. По форме представления информации можно выделить мультимедийные системы баз данных, в которых, помимо текстовых, числовых и графических данных имеются аудио-, видео- и мультимедийная информация, а также имеются средства поиска мультимедийных данных. КЛАССИФИКАЦИЯ МОДЕЛЕЙ ДАННЫХ Центральным понятием в области баз данных является понятие модели. Модель данных — это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними. В соответствии с рассмотренной ранее трехуровневой архитектурой приходится сталкиваться с понятием Инфологические модели используются на ранних стадиях проектирования баз данных для формального описания предметной области. Они содержат информацию о классах объектов, их свойствах и взаимосвязях, описания структур данных без привязки к какой-либо конкретной СУБД. Инфологические (или семантические) модели отражают в естественной и удобной для разработчиков и других пользователей форме информацию о предметной области в процессе разработки структуры будущей базы данных. Физическая модель данных оперирует категориями, касающимися организации внешней памяти и структур хранения, используемых в данной операционной среде. В настоящий момент в качестве физических моделей используются различные методы размещения данных, основанные на файловых структурах: это организация файлов прямого и последовательного доступа, индексных файлов и инвертированных списков. Кроме того, современные СУБД широко используют страничную организацию данных. В этом случае база данных представлена минимальным количеством файлов, а задачи поиска, чтения и записи данных выполняет сама СУБД, а не операционная система. Физические модели данных, основанные на страничной организации, являются наиболее перспективными. Наибольший интерес вызывают модели данных, используемые на концептуальном уровне. По отношению к ним внешние модели называются подсхемами и используют те же абстрактные категории, что и концептуальные модели данных. Даталогические модели являются моделями концептуального уровня и разрабатываются для конкретной СУБД. Документальные модели данных соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке. Модели, ориентированные на формат документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. Гораздо более простой и удобный, чем SGML, язык HTML (HyperText Markup Language – язык разметки гипертекста) позволяет определять оформление элементов документа и имеет некий ограниченный набор инструкций — тегов, при помощи которых осуществляется процесс разметки. Инструкции HTML в первую очередь предназначены для управления процессом вывода содержимого документа на экране программы-клиента и определяют этим самым способ представления документа, но не его структуру. В качестве элемента гипертекстовой базы данных, описываемой HTML, используется текстовый файл, который может легко передаваться по сети с использованием протокола HTTP. В настоящее время все большую популярность приобретает язык XML (eXtensible Markup Language – расширяемый язык разметки), позволяющий описывать документы произвольной структуры и содержания. Тезаурусные модели основаны на принципе организации словарей. Они содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых. Принцип хранения информации в этих системах и подчиняется тезаурусным моделям. Дескриптпорные модели — самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор — описатель. Этот дескриптор имеет жесткую структуру и описывает документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной базе данных. Например, для БД, содержащей описание патентов, дескриптор содержит название области, к которой относился патент, номер патента, дату выдачи патента и еще ряд ключевых параметров, которые заполнялись для каждого патента. Обработка информации в таких базах данных ведется исключительно по дескрипторам, то есть по тем параметрам, которые характеризуют патент, а не по самому тексту патента. Теоретико-графовые модели отражают совокупность объектов реального мира в виде графа взаимосвязанных информационных объектов. Математической основой таких моделей является теория графов. Реляционная модель будет подробно рассмотрена далее. ОСНОВНЫЕ ТИПЫ ДАННЫХ Перечень типов данных, доступных при разработке баз данных, зависит от особенностей СУБД. В общем случае, в различных типах СУБД применяемые типы данных могут несколько отличаться, как названиями, так и особенностями программной реализации. Текстовые данные - представляют собой набор алфавитно-цифровых и специальных используются в БД для обозначения имен, фамилий, адресов, названий объектов, кратких характеристик, а также для обозначения имен файлов, содержащих неструктурированную информацию произвольной длины. Некоторые СУБД для хранения неструктурированной текстовой информации предлагают специальный тип данных MEMO. Главной характеристикой текстового поля является его размер. Слишком большой размер текстового поля приводит к излишней трате дисковой и оперативной памяти и снижению эффективности БД. Уменьшение длины текстового поля может привести к потере информации. Обычно текстовые поля создают, по возможности, минимально необходимой длины, а при необходимости – увеличивают размер поля. Текстовые поля можно сравнивать между собой (совпадают/не совпадают) и сортировать по возрастанию/убыванию (в алфавитном порядке). Числовые данные - используются для представления атрибутов, со значениями которых нужно в дальнейшем производить арифметические операции (цены, веса, коэффициенты и т.д.). Часто целые типы данных вместе с целочисленной арифметикой рассматриваются отдельно от рациональных чисел. Для хранения целого числа требуется повышенной (двойной) точности могут принимать значения из большего диапазона и имеют больше значащих цифр за счет увеличения размера памяти, отведенного для хранения числа. Например, наибольшая абсолютная величина числа типа «длинное целое», случаем числовых данных является тип «денежный», отличающийся повышенной точностью и фиксированным положением десятичной точки. Внешний вид числа на экране кроме типа определяется параметрами форматирования. Так, например, обычно можно указать число знаков после десятичной точки или процентный формат представления числа. Логические данные используются при составлении логических выражений. Некоторые СУБД не имеют отдельного логического типа данных, а рассматривают его как частный истолкованы как «ДА»/«НЕТ» или «ЕСТЬ»/«НЕТ». Дата/время - записываются в некотором жестком формате, например, ДД.ММ.ГГГГ (день, месяц, год) или ЧЧ:ММ:СС (часы, минуты, секунды). Формат отображения данных на экране зависит от настроек локализации программного обеспечения и может не совпадать с форматом хранения. Так, американскому формату ММ.ДД.ГГГГ и европейскому ДД.ММ.ГГГГ соответствует одинаковое внутреннее представление даты. С полями данных типа дата/время можно выполнять операции строгого (равно/не равно) и нестрогого сравнения (больше/меньше, т.е. раньше/позже), сортировки по возрастанию/убыванию (в прямом или обратном хронологическом порядке), а также операцию вычитания для определения временного промежутка между событиями). Объект OLE (Object Linking and Embedding – связь и внедрение объектов). «Значением» поля с типом данных «Поле объекта OLE» является объект OLE, внедренный в базу данных. С помощью такого поля создаются мультимедийные базы данных, т.к. в качестве «данного» могут быть использованы графика, звук, видео. Объектом OLE называется произвольный элемент, созданный средствами какого-либо приложения Windows, который можно поместить (внедрить) в документ другого приложения Windows. Приложение, средствами которого создается объект OLE (т.е. программа, которая обслуживает другое приложение) называется сервером OLE. Приложение, принимающее объект OLE (т.е. программа, которая пользуется услугами OLE-сервера), называется клиентом OLE. Технология OLE позволяет значительно расширить возможности даже простых баз данных. Например, база данных о свойствах сложных химических соединений может включать не только брутто-формулу вещества, но и структурную формулу (или трехмерную структуру) вещества, а также изображение спектра поглощения, фотографию кристаллической структуры и т.д. ОТНОШЕНИЯ МЕЖДУ ДАННЫМИ Данные об объектах (сущностях) в базе данных связаны между собой отношениями (связями). Обычно рассматривают три их типа. только один экземпляр объекта В и, наоборот, любому экземпляру объекта В может соответствовать только один экземпляр объекта А. Например, отношение один-к-одному может быть применено к объектам ДЕКАН и ФАКУЛЬТЕТ предметной области ВУЗ. Такую связь можно трактовать следующим образом: на каждом факультете есть один декан, каждый декан является руководителем одного факультета. соответствует несколько (более одного) экземпляра объекта В. Например, отношение один-ко-многим может быть применено к объектам ГРУППА и СТУДЕНТ предметной области ВУЗ: в группе учится много студентов, но каждый студент учится только в одной группе. Многие-ко-многим (M:N) – когда может существовать экземпляр объекта А, которому соответствует несколько экземпляров объекта В и, наоборот, одному экземпляру объекта В может соответствовать несколько экземпляров объекта А. Например, отношение многие-ко-многим может быть применено к объектам ПРЕПОДАВАТЕЛЬ и ПРЕДМЕТ предметной области ВУЗ. Каждый преподаватель может вести занятия по нескольким предметам, каждый предмет могут вести несколько преподавателей. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ Теоретической основой реляционной модели является теория отношений. В руководствах по теории отношений было показано, что множество отношений и несколько специальных операций образуют абстрактную алгебру. Это важнейшее свойство отношений было использовано в реляционной модели для разработки языка манипулирования данными, сформулировал основные понятия и ограничения реляционной модели, ограничив набор операций в ней семью основными и одной дополнительной операцией. ОСНОВНЫЕ ПОНЯТИЯ РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ Основной структурой данных в модели является отношение, именно поэтому модель получила название реляционной (от английского relation — отношение). С точки зрения пользователя, синонимом к понятию отношение может выступать понятие таблица, т.е. в реляционной модели данных хранятся в виде набора связанных между собой таблиц. Рассмотрим несколько определений. Сущность – это любой различимый, отличный от других, реальный или воображаемый, объект, информация о котором будет храниться в базе данных. Понятие сущности относится к основополагающим понятиям теории баз данных и используется для моделирования класса однотипных объектов. В рамках рассматриваемой предметной области в процессе ее анализа выделяются сущности (классы объектов) и экземпляры объектов. Например, для химической базы данных можно выделить сущность (класс объектов) ХИМИЧЕСКИЙ ЭЛЕМЕНТ и экземпляры объектов – отдельные химические элементы, например, ВОДОРОД или ГЕЛИЙ. Каждый класс объектов имеет свое уникальное в рамках предметной области имя, позволяющее отличить одну сущность от другой. Каждый объект, относящийся к данной сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного класса объектов и позволяющих однозначно идентифицировать объект и отличить его от других. Все экземпляры объектов, принадлежащие одной сущности, имеют одинаковый набор атрибутов и различаются только значениями атрибутов. Так, например, сущность ХИМИЧЕСКИЙ ЭЛЕМЕНТ имеет такие атрибуты, как ПОРЯДКОВЫЙ НОМЕР, НАИМЕНОВАНИЕ, СИМВОЛ, АТОМНАЯ МАССА и ряд других. Каждый атрибут сущности имеет свое уникальное имя, однако разные сущности могут иметь одинаковые названия атрибутов. Например, атрибут ПОРЯДКОВЫЙ НОМЕР может быть у любого упорядоченного множества объектов. Домен – это диапазон значений, которые может принимать атрибут. Домен может быть задан перечислением возможных значений либо в абстрактном виде. Например, атрибут ДЕНЬ НЕДЕЛИ может принимать значения из ограниченного множества {«Пн», «Вт», «Ср», «Чт», «Пт», «Сб», «Вс»}, а атрибут ПОРЯДКОВЫЙ НОМЕР относится к домену целых положительных чисел. Различные атрибуты объекта могут принимать значения из одного и того же домена, например, ПОРЯДКОВЫЙ НОМЕР и АТОМНАЯ МАССА относятся к домену целых положительных чисел. Таким образом, каждой сущности соответствует таблица. Атрибуты сущности являются заголовками столбцов, а строки таблицы называются записями и содержат значения атрибутов для различных экземпляров объектов. Для описания структуры таблицы необходимо перечислить имена атрибутов соответствующей сущности и указать домены, к которым они относятся. Рассмотрим пример таблицы, описывающей класс объектов ХИМИЧЕСКИЙ ЭЛЕМЕНТ. ПОРЯДКОВЫЙ НОМЕР НАИМЕНОВАНИЕ СИМВОЛ АТОМНАЯ МАССА ПОРЯДКОВЫЙ НОМЕР – целое положительное число; НАИМЕНОВАНИЕ – набор текстовых символов; СИМВОЛ – одна или две латинские буквы (кроме некоторых трансурановых элементов); АТОМНАЯ МАССА – целое положительное число. СВОЙСТВА ОТНОШЕНИЙ Любая реляционная таблица (отношение) имеет ряд специфических свойств: Для того, чтобы отличить запись одну от другой (и таким образом идентифицировать конкретный объект как экземпляр сущности, описываемой данным отношением), каждая таблица должна иметь первичный ключ. В качестве первичного ключа (PRIMARY KEY) может выступать одно или несколько полей таблицы, содержащее уникальное значение для каждой записи. Например, в отношении, характеризующим сущность ХИМИЧЕСКИЙ ЭЛЕМЕНТ, первичным ключом будет являться атрибут ПОРЯДКОВЫЙ НОМЕР, поскольку все химические элементы имеют различные порядковые номера, соответствующие числу протонов в ядре элемента. Первичный ключ однозначно определяет значения остальных атрибутов отношения, не входящих в состав первичного ключа, которые называются неключевыми. В таком случае говорят о наличии функциональной зависимости неключевых атрибутов от первичного ключа. В таблице может быть несколько потенциальных ключей, но в качестве первичного должен быть выбран только один из них. Потенциальный ключ не должен быть избыточным, т.е. в состав ключа должно входить минимально необходимое для идентификации записи множество атрибутов. Например, сущность ИЗОТОП характеризуется следующими атрибутами: НАИМЕНОВАНИЕ ЭЛЕМЕНТА, СИМВОЛ, ЧИСЛО ПРОТОНОВ, ЧИСЛО НЕЙТРОНОВ, МАССОВОЕ ЧИСЛО. Потенциальными ключами являются пары атрибутов {ЧИСЛО ПРОТОНОВ, ЧИСЛО НЕЙТРОНОВ}, {ЧИСЛО НЕЙТРОНОВ, МАССОВОЕ ЧИСЛО}, {ЧИСЛО ПРОТОНОВ, МАССОВОЕ ЧИСЛО}. СИМВОЛ ЭЛЕМЕНТА ЧИСЛО ПРОТОНОВ ЧИСЛО НЕЙТРОНОВ МАССОВОЕ ЧИСЛО ОБОЗНАЧЕНИЕ ИЗОТОПА H H H He He На практике для обозначения изотопов используют преимущественно пару атрибутов {ЧИСЛО ПРОТОНОВ, МАССОВОЕ ЧИСЛО}, поскольку именно порядковый номер определяет химические свойства элемента, а массовые числа позволяют отличить один изотоп от другого и близки к относительной атомной массе, приводимой в периодической таблице элементов, в то время как число нейтронов в ядре представляет интерес, в основном, в ядерной физике. В качестве первичного ключа рекомендуется выбирать поля типа «длинное целое», поскольку обработка числовых полей происходит намного эффективнее, чем текстовых. Выбор составного первичного ключа из нескольких текстовых полей может серьезно ухудшить производительность СУБД. В случае, если первичный ключ подобрать сложно, либо он достаточно громоздок, рекомендуется создавать искусственный идентификатор в виде поля «длинное целое» и заполнять его уникальными значениями, кодирующими записи исходной таблицы. СВЯЗЫВАНИЕ ТАБЛИЦ Реляционная база данных состоит из множества взаимосвязанных отношений (таблиц). Для обеспечения связи между таблицами в одной из связанных таблиц следует предусмотреть так называемый внешний ключ (FOREIGN KEY). Это поле (или совокупность полей) того же типа, что и первичный ключ в исходной таблице. Значения атрибутов, входящих в исходную и связанную таблицы, также должны совпадать для связанных записей. В то же время наименования связанных полей совпадать не обязаны. В реляционных базах данных непосредственно моделируются два типа связей: «один-к-одному» и «один-ко-многим». Связи типа «один-к-одному» встречаются на практике довольно редко. В качестве примера можно привести наличие единственного высшего оксида у металлов главных подгрупп периодической системы, формула которого определяется максимальной валентностью элемента, а та, в свою очередь – номером они используются для разграничения доступа пользователей к определенной информации в базе данных и для создания различных внешних представлений для приложений БД. Например, в бухгалтерии имеется информация о зарплате сотрудника и его табельном номере, а в отделе кадров – только его табельный номер и должность. Порядковый номер (первичный ключ) Номер группы Символ Порядковый номер (внешний ключ) Формула высшего оксида иерархических связей между различными сущностями. Например, для справочника неорганических соединений такая связь будет между таблицей химических элементов и Порядковый номер (первичный ключ) Символ Порядковый номер (внешний ключ) Степень окисления Формула оксида химическому элементу соответствует (может соответствовать) много оксидов». Значения первичного ключа в исходной таблице должны быть уникальны для разных записей, в то время как значение внешнего ключа в связанной таблице может дублироваться многократно. НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ Нормализация – процесс удаления избыточных данных из таблицы путем декомпозиции отношений, т.е. разбиения исходного отношения на множество более простых отношений. Многократное дублирование информации в базе данных приводит к снижению производительности СУБД. Каждый элемент данных должен храниться в базе в одном и только одном экземпляре. Нормализация базы данных сокращает избыточность информации, способствует поддержке непротиворечивости информации в БД, повышает скорость выполнения различных операций. Предпочтительнее всего уделить внимание нормализации базы данных на стадии проектирования, поскольку внесение изменений в готовый проект или, тем более, работающую базу данных связано со значительными трудозатратами. Процесс нормализации основан на понятии функциональной зависимости атрибутов. Атрибут В функционально зависит от атрибута А (обозначается А ->В), если в любой момент времени каждому значению атрибута А соответствует не более одного значения атрибута В. Термин функциональная зависимость соответствует понятию функции в математике. Если неключевой атрибут зависит от всего составного ключа и не зависит от его частей, то говорят о полной функциональной зависимости атрибута от составного ключа. Если атрибут А зависит от атрибута В, а В зависит от атрибута С, но обратная зависимость отсутствует, то говорят о транзитивной зависимости атрибута С от А. Принято говорить, что нормализованная база данных находится в одной из нормальных форм. Существует пять распространенных форм нормализации, каждая последующая нормальная форма основана на предыдущей. Отношение находится в некоторой нормальной форме, если удовлетворяет свойственному данной форме набору ограничений. Как правило, на практике база данных приводится к третьей нормальной форме, последние две считаются слишком узкоспециализированными, чтобы их применять к обычным проектам баз данных. Базы данных в третьей нормальной форме: не содержат повторяющихся групп данных; не содержат неполных функциональных зависимостей неключевых атрибутов от составных первичных ключей; не содержат функциональных зависимостей одних неключевых атрибутов от других (все неключевые атрибуты взаимно независимы). ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА Отношение находится в первой нормальной форме тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные (неделимые) значения атрибутов и не содержатся повторяющиеся группы. Например, неделимых полей, таких, как «Улица» (текстовое), «Дом» (целое) и т.п. Кроме того, из поля «Телефон» требуется выделить новое поле для хранения информации о типе телефонного номера. В то же время поле «Телефон» может содержать несколько номеров телефонов (например, рабочий, домашний, мобильный и т.д.). Для исключения повторяющейся группы – множества номеров телефонов – следует выделить для каждого номера телефона отдельную запись и дополнить соответствующими значениями остальные поля новых записей. Имя Адрес Телефон Имя Улица Дом Квартира Телефон Тип телефона ВТОРАЯ НОРМАЛЬНАЯ ФОРМА Для того чтобы привести таблицу ко второй нормальной форме, нужно, чтобы все неключевые атрибуты полностью зависели от первичного ключа таблицы. Это значит, что каждое неключевое поле должно уникально определяться первичным ключом и полями, его составляющими. Если первичный ключ таблицы состоит из одного атрибута, это условие выполняется автоматически. Если первичный ключ состоит из нескольких полей, то ни один из неключевых атрибутов не должен функционально зависеть от любой части составного первичного ключа. Рассмотрим пример с периодической таблицей элементов. В качестве составного первичного ключа таблицы может выступать совокупность номера периода и номера группы, однозначно определяющая химический элемент. В то же время формула высшего оксида функционально зависит лишь от части составного первичного ключа данной таблицы, а именно – от номера группы. Для того, чтобы привести таблицу ко второй нормальной форме, следует разбить ее на две связанные таблицы. В новую таблицу войдут номер группы в качестве первичного ключа и функционально зависящая от него формула высшего оксида. В старой таблице номер группы останется, с одной стороны, как часть первичного ключа, а с другой стороны – как внешний ключ для связи с новой таблицей. Период Группа Символ Название Оксид Период Группа Символ Название Группа Оксид ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА Для того чтобы таблица была приведена к третьей нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и не зависели друг от друга. Таким образом, к ограничениям, накладываемым второй нормальной формой, добавляется требование взаимной независимости каждого неключевого поля таблицы от любого другого неключевого поля. Рассмотрим другой вариант отношения «Периодическая система». Первичным ключом таблицы является порядковый номер элемента. В отличие от предыдущего примера, данное отношение находится во второй нормальной форме, поскольку номер группы не входит в состав первичного ключа. Тем не менее в данном отношении имеется нежелательная функциональная зависимость формулы высшего оксида от номера группы, что будет приводить к рассмотренным ранее аномалиям. Для устранения зависимости неключевого атрибута «Оксид» от неключевого атрибута «Группа» исходную таблицу следует разбить на две. Первичным ключом новой таблицы станет поле «Группа». В исходной таблице поле «Группа» останется неключевым, но станет внешним ключом для обеспечения связи с новой таблицей. Номер Символ Название Группа Оксид Номер Символ Название Группа Группа Оксид ПРОЕКТИРОВАНИЕ НОРМАЛИЗОВАННЫХ ОТНОШЕНИЙ Для идентификации отдельных записей (конкретных объектов реального мира) в каждой таблице должен быть определен первичный ключ: либо простой, либо составленный из нескольких атрибутов, либо на основе искусственно введенного кода записи (объекта). Введение кодов информации с одной стороны облегчает нормализацию баз данных, а с другой стороны –сокращает время ввода новых данных и количество ошибок при вводе. Кроме того, введение искусственных идентификаторов позволяет легче осуществить изменение значений атрибутов, поскольку неключевые атрибуты хранятся только в одном месте. Моделирование связей типа «многие-ко-многим» в рамках реляционной модели данных осуществляется при помощи вспомогательного отношения. Рассмотрим предметную область, связанную с поставками различных видов топлива, произведенных несколькими топливными компаниями, на различные АЗС, входящие в сети бензоколонок. В данной предметной области можно выделить такие сущности, как «Виды топлива», «Поставщики» и «Клиенты», причем между всеми этими сущностями имеются связи типа «многие-ко-многим». Каждый поставщик производит и продает много видов топлива, а каждая АЗС, в свою очередь, покупает эти различные виды топлива. При этом один вид топлива производится и покупается многими топливными компаниями и АЗС. Перечислим важные в рамках заданной предметной области атрибуты указанных сущностей. К атрибутам поставщика топлива относится его наименование. Марки топлива характеризуются наименованием по ГОСТ и кратким наименованием. В роли клиентов выступают АЗС, расположенные по указанному адресу и имеющие свой номер в сети АЗС. Сделки на поставку топлива характеризуются суммой, а также датой и объемом поставки. Кроме указанных атрибутов, каждое отношение, описывающее рассмотренные сущности, будет содержать свой первичный ключ, а отношение «Поставки» – набор внешних ключей для связи с остальными отношениями (все связи будут иметь тип «один-ко-многим»). Сущность Атрибут Домен (тип и размер данных) Номер Целое число Поставки Сумма Денежное Дата Дата/время Объем Числовое с плавающей точкой Таблица «Поставки» является вспомогательной для моделирования связей типа «многие-ко-многим» между остальными сущностями, в то время как с точки зрения ввода и редактирования информации эта же таблица будет являться основной, а остальные будут играть роль справочников. Таким образом, в результате нормализации базы данных получен ряд справочных таблиц, классификаторов, списков объектов и т.д., данные в которых меняются относительно редко, и основная операционная таблица, в которой, в основном, осуществляется ввод и редактирование основных объемов поступающей информации.


Внимание! Не забудьте ознакомиться с остальными документами данного пользователя!

Соседние файлы в текущем каталоге:

На сайте уже 21970 файлов общим размером 9.9 ГБ.

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

Не нашли нужный документ? Воспользуйтесь поиском по содержимому всех файлов сайта:



Каждый день, проснувшись по утру, заходи на obmendoc.ru

Товарищ, не ленись - делись файлами и новому учись!

Яндекс.Метрика