Размещено на http://www.allbest.ru/

План

Введение

1. Система баз данных

2. Проектирование баз данных

3. Даталогическое проектирование

Введение

Использование баз данных является неотъемлемой составляющей при создании и использовании любых автоматизированных информационных систем. В связи с этим весьма актуальным является изучение и освоение процессов проектирования и применения различных систем баз данных.

Можно выделить четыре этапа в развитии баз данных.

1 этап связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС ЭВМ и мини-ЭВМ типа PDP11. На данном этапе многие функции по управлению данными возлагались на операционную систему. Значительная роль отвадилась по администрированию данных.

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

3 этап - распределенные базы данных. История развития идет по спирали, после процесса "персонализации", начался обратный процесс - интеграция. Появляются сети, информация передается между компьютерами, возникают задачи, связанные с параллельной обработкой транзакций. Появляется технология распределенных баз данных. Данная технология характеризуется следующими особенностями:

· Все СУБД поддерживают реляционные модели данных;

· Язык запросов - SQL;

· Большинство СУБД рассчитаны на многоплатформенную архитектуру;

· Осуществляется поддержка многопользовательского режима работы с базой данных;

· Используется технология "клиент-сервер".

4 этап характеризуется появлением новой технологии доступа к данным - интранет. В отличие от технологии "клиент-сервер", отпадает необходимость использования специализированного клиентского приложения. Для работы с удаленной базой данных используется стандартный браузер (например, Internet Explorer или Netscape Navigator).

СУБД - это программный продукт, поддерживающий процессы создания, ведения и использования БД.

Различают: полнофункциональные СУБД, серверы БД, клиенты БД,

средства разработки программ работы с БД. Полнофункциональные - это наиболее многочисленные и мощные СУБД по своим возможностям. К ним можно отнести следующие системы: Clarion, Database Developer, Data Ease, dBase IV, Microsoft Access, Microsoft FoxPro, Paradox. Они имеют развитый интерфейс, удобный язык запросов.

Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Реализуют функции управления БД при запросах от клиентов с помощью операторов SQL. К ним можно отнести: NetWare SQL (Novell), MS SQL Server (Microsoft), Inter Base (Borland), SQL Base Server (Gupta), Intelligent Database (Ingress).

Клиенты - это различные программы: полнофункциональные СУБД, электронные таблицы, текстовые процессоры, программа электронной почты и др.

Существуют следующие средства разработки программ работы с БД

Это инструментальные средства: Delphi, Power Builder (Borland), Visual Basic (Microsoft), Erwin (Logic Works).

По характеру использования СУБД делятся на: персональные и многопользовательские.

Персональные СУБД: Visual FoxPro, Paradox, Clipper, dBase, Access и др. Многопользовательские СУБД, включают в себя сервер БД и клиентскую часть: Oracle, Informix

По используемым моделям данных СУБД (как и БД) разделяются на следующие модели: иерархические, сетевые, реляционные, объектно-ориентированные и др.

1. Система баз данных

База данных является современной формой организации хранения и доступа к информации.

В отечественной литературе первоначально широко использовался термин "Банк данных", что соответствовало зарубежному термину "Система баз данных (database system)". Но в настоящее время термины "Банк данных", "Система баз данных" часто заменяются общим названием "Система управления базой данных (СУБД)". С учетом, что современные системы баз данных являются многофункциональными, предназначенными как для хранения информации, так и для решения различных прикладных задач: программирование, моделирование, проектирование, бизнес-анализ и т.д., то такие системы, по сути, являются информационными системами (Information Systems).

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

На рис.1.1 представлен состав автоматизированной информационной системы. Такая система включает следующие средства: СУБД - система управления базой данных; ТС - технические средства; ОС - операционная система; ОМС - организационно - методические средства; АБД - администратор банка данных.

АИС является сложной человеко-машинной системой, включающей в свой состав различные взаимосвязанные и взаимозависимые компоненты.

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

Система управления базой данных (СУБД) - это совокупность программных и языковых средств общего или специализированного назначения, необходимая для создания БД, поддержания их в актуальном состоянии и организации доступа к ним различных пользователей в условиях принятой технологии обработки данных.

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

- программы управления данными (ядро СУБД);

- трансляторы с языков банка данных;

- вспомогательные программы (утилиты);

- прикладные программы пользователей.

Языковые средства СУБД. Языковые средства обеспечивают интерфейс пользователей с банком данных. Языковые средства современных СУБД относятся к языкам четвертого поколения (первое поколение - машинные языки, второе поколение - символические языки типа Ассемблера, третье поколение - алгоритмические языки типа Паскаль, Фортран, четвертое поколение - 4GL).

Спектр языковых средств, применяемых в СУБД, представлен на рис. 1.2



Рис. 1.2. Языковые средства СУБД:

ЯОД - язык описания данных, ЯМД - язык манипулирования данными,

ЯО - язык описания, QBE и SQL - языки запросов

В процедурных языках надо указать, какие действия и над какими объектами необходимо выполнить, чтобы получить результат. В непроцедурных языках указывается, что надо получить, а не как этого достичь. Примерами непроцедурных языков являются языки, с реляционным исчислением (SQL).

В рамках одной СУБД могут использоваться языки разных типов. Например, в dBASE4 используются: процедурные языки программирования; табличный язык запросов QBE; язык SQL, язык исчисления кортежей.

Технические средства. Могут использоваться большие, средние ЭВМ и персональные компьютеры.

Организационно - методические средства (ОМС). ОМС представляют собой различные инструкции, методические и регламентирующие материалы.

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

- системные аналитики;

- проектировщики структур данных;

- проектировщики технологических процессов обработки данных;

- системные и прикладные программисты;

- операторы, специалисты по техническому обслуживанию;

- специалисты по маркетингу (для коммерческих банков данных).

Функции, выполняемые АБД.

1. Анализ предметной области, определение потребностей пользователей.

2. Проектирование структуры БД.

3. Первоначальная загрузка и ведение БД.

4. Защита данных:

- обеспечение парольного входа;

-обеспечение защиты данных(выбор / создание пограммно-технологических

средств защиты данных);

- тестирование средств защиты;

- фиксация попыток несанкционированного доступа к информации.

5. Обеспечение восстановления БД, организация ведения системных журналов.

6. Сбор статистики обращений пользователей к БД.

7. Подготовка и поддержание системных программных средств.

Преимущества банка данных.

1.Сокращение избыточности хранимых данных за счет интегрированного хранения.

2. Улучшение деятельности организации благодаря сокращению документооборота, форм документов.

3. Устранение противоречивости данных.

4. Многоаспектное использование данных.

5. Обеспечение защиты, целостности, секретности.

6. Обеспечение независимости прикладных программ (ПП) от пользователей.

Требования к банкам данных

1.Адекватность отображения предметной области (полнота, целостность и непротиворечивость данных, актуальность информации, т. е. соответствие состоянию объекта на данный момент времени).

2.Возможность взаимодействия пользователей разных категорий и в разных режимах.

3. Дружелюбность интерфейсов и малое время на освоение системы.

4. Обеспечение секретности.

5. Обеспечение взаимной независимости программ и данных.

6. Обеспечение надежности функционирования банка данных: защита данных от разрушения, возможность восстановления.

Классификация баз данных

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

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

2. БД с символьными данными делятся: неструктурированные; частично структурированные; структурированные. К неструктурированным БД могут быть отнесены БД, организованные в виде семантических сетей. Частично структурированные - в виде обычного текста или гипертекстовые системы. Структурированные - имеют определенные форматы для хранения данных и их связи.

3. Структурированные БД по типу используемой модели делятся на: иерархические; сетевые; реляционные; смешанные; мультимедийные. Наибольшее коммерческое использование имеют реляционные системы.

4. По типу хранимой информации БД делятся на документальные (библиографические, реферативные и полнотекстовые); фактографические; лексико-графические (словари, классификаторы и т. д.);

5. По характеру организации хранения данных БД подразделяются на локальные (персональные); общие (интегрированные); распределенные.

6. По охвату предметной области БД делятся на: территориальные (страна, область, город...); временные (год, месяц, ...);

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

Архитектура баз данных

В базе данных отражается информация о предметной области (ПО)(рис 1.3) . В автоматизированных информационных системах (АИС) отражение ПО представлено моделями нескольких уровней.

Рис.1.3. Отображение ПО в БД с помощью модели предметной области

Модель данных - это представление данных и их взаимосвязей, описывающих понятия проблемной среды. Модель имеет свою схему, в которой отражена структура данных, имена записей, имена и форматы полей.

На СУБД возлагается задача реализации отображения (прямого и обратного).

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

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

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

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

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



Рис. 1.4. Трехуровневая архитектура БД:

П - пользователи, ПП - прикладные программы, РО - рабочие области, ОС -операционная система, ВМД - внешняя модель данных, КМД - концептуальная модель данных, ВнМД - внутренняя модель данных

2. Проектирование баз данных

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

Алгоритм процесса проектирования представлен на рис. 2.1



Рис.2.1. Этапы проектирования

Рассмотрим подробнее каждый этап.

1. Системный анализ предметной области.

На этом этапе необходимо:

- обосновать актуальность разработки базы данных и автоматизированной системы;

- подробно описать предметную область и основные ограничения;

- выделить основные объекты этой ПО, их свойства и связи между собой;

- определить круг пользователей системы и их информационные потребности;

- исследовать документооборот системы;

- Определить круг задач, которые будут решаться в автоматизированной среде и т. д.

Например, пусть разрабатывается БД "Библиотека". Системный анализ может выглядеть примерно так:

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

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

- Информация о читателях должна быть полной и достаточной для определения категории читателя, его места жительства и места работы. Необходимо учесть, что среди читателей могут быть однофамильцы, поэтому у каждого читателя должен быть уникальный абонентский номер.

- Ограничения при работе библиотеки:

1. Книга может не иметь ни одного автора, например, сборник тезисов научной конференции;

2. Каждая книга может относиться к множеству областей знаний и к каждой области знаний относится множество книг;

3. Книги, изданные до 1970 года должны быть списаны, и в библиотеке их нет;

4. Читатели старше 17 лет;

5. Каждый читатель может иметь на руках не более 5 книг;

6. Каждый читатель должен иметь рабочий или домашний телефон; и т. д.

Таких ограничений может быть и больше; они могут быть другими или их вообще может не быть, в зависимости от библиотеки, для которой разрабатывается база данных.

- Работать с базой данных "Библиотека" будут следующие пользователи:

библиотекари, читатели, дирекция библиотеки.

Библиотекари должны иметь возможность систематизировать книжный фонд, т.е. распределять книги по разным каталогам, добавлять новые книги и списывать старые, вести учет выдачи и возврата книг, записывать нового читателя в библиотеку или закрывать абонент читателя.

Читатель должен иметь возможность просматривать каталоги книг по разделам, по авторам и получать информацию о наличие книги и возможности ее получения.

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

Задачами автоматизированной системы являются:

1. Запись читателя в библиотеку;

2. Поиск и выдача книги читателю;

3. Отметка о возврате книг читателем;

4. Закрытие абонента читателя;

5. Пополнение книжного фонда;

6. Систематизация книг по каталогам;

7. Списание книг;

8. Подготовка списка книг по разделам;

9. Подготовка сведений о книгах по авторам;

10. Подготовка сведений о читателях - должниках, с указанием суммы взыскания;

11. Подготовка списка книг на списание;

12. Подготовка списка книг на закупку библиотекой, с указанием необходимой суммы для их приобретения.

Определим основные объекты этой системы и их свойства.

1. КНИГА

-уникальный шифр книги (ISBN)

- название

-фамилии авторов

- издательство

-город издания

-год издания

-количество страниц в книге

-стоимость книги

-количество экземпляров в библиотеке

- номер области знаний, к которой относится данная книга

2. ЧИТАТЕЛЬ

-номер читательского билета

-фамилия, имя, отчество

-дата рождения

- домашний адрес

-место работы и т.д.

3. ЭКЗЕМПЛЯР

-уникальный инвентарный номер книги

-место размещения в библиотеке (ряд -полка)

-читательский (абонентский) билет с информацией о читателях, пользовавшихся этим экземпляром: номер читательского билета, дата выдачи книги и дата возврата.

Это только пример описания ПО; реально оно должно быть более подробным.

2. Инфологическое проектирование.

Так как процесс проектирования БД - это процесс длительный, итерационный, то для получения максимально положительного результата необходимо иметь такое представление модели БД, которое было бы представительным и понятным, особенно заказчику; т.е. должно быть некое формализованное описание БД, но без относительно к конкретной СУБД. В настоящее время на этапе инфологического проектирования используется в основном, так называемая, ER - модель (ENTITY RELATIONSHIP), т.е. модель "СУЩНОСТЬ - СВЯЗЬ".

В основе ER модели лежат следующие понятия:

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

- Атрибут - это поименованная характеристика сущности. Причем набор атрибутов должен быть таким, чтобы различные экземпляры отличались друг от друга. Например, сущность Студент может характеризоваться атрибутами: Номер_зачетной_книжки, ФИО, Номер_группы, Номер_факультета, Номер_специальности, и т.д.

Графическое представление этой сущности в ER модели такое:

Здесь присутствует связь М:1, т.к. Каждый преподаватель может руководить дипломным проектированием нескольких студентов, в то время, как руководитель у каждого студента только один.

В этом случае связь М:М, т.к. каждый преподаватель читает лекции многим студентам и, в свою очередь, каждый студент слушает лекции многих преподавателей.

Таким образом, связи делятся по множественности и могут быть:

1:1 (один к одному), 1:М (один ко многим), М:М (многие ко многим).

Вернемся теперь к примеру "Библиотека" и представим ее ER модель.

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

Общая схема базы данных "Библиотека" представлена на рис.2.2

Рис.2.2. Концептуальная модель базы данных "Библиотека"

Этап 3. Выбор СУБД.

На этом этапе необходимо обосновать выбор той или иной СУБД, предварительно изучив их параметры. При этом можно обратить внимание

на объемы необходимой оперативной памяти, наличие у вас операционной системы, под которой работает СУБД, должна ли ваша система работать в сети, стоимость СУБД и т.д. Одним из основных параметров при выборе системы может служить также модель данных, поддерживаемая данной СУБД: иерархическая, сетевая или реляционная.

Иерархическая модель данных

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

Рис. 2.3. Графическое изображение иерархической структуры БД

Можно выделить основные особенности иерархической модели БД:

1. Все типы связей функциональные, т.е. 1:1, 1:М.

2. Структура связей древовидная.

3. Иерархия всегда начинается с корневого узла.

4. На первом уровне (i=1) может находиться только один узел - корневой.

5. На нижних уровнях (i = 2, 3, ..., n) находятся порожденные (зависимые) узлы.

6. Каждый порожденный узел, связан только с одним непосредственно исходным узлом.

7. Каждый исходный узел может иметь один или несколько непосредственно порожденных узлов, которые называются подобными.

8. Доступ к каждому порожденному узлу выполняется через его непосредственно исходный узел.

9. Существует единственный иерархический путь доступа к любому узлу, начиная от корня дерева.

Иерархический путь включает все связанные между собой узлы, начиная с корневого узла и кончая заданным. Иерархический путь является линейным, т. к. все узлы встречаются по одному разу. Среди систем, в основе которых лежат иерархические модели данных, наибольшее распространение получили ОКА и ИНЕС.

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

Сетевые модели

Если порожденный элемент в отношении между данными имеет более одного исходного элемента, то это отношение нельзя описать как древовидную или иерархическую структуру. Его описывают в виде сетевой структуры. Любой элемент в сети может быть связан с любым другим элементом

Рис.2.4. Примеры сетевых структур

Наиболее известными СУБД, поддерживающими сетевые структуры являются СИОД 1, СИОД 2, ПАРМА, ВИБ-СМ, СЕДАН (СЕТОР), Банк, СЕТЬ, Адабас, IDMS, IDS.

Особенности сетевой модели данных:

1. Любой узел может быть как исходным, так и порожденным.

2. Любой узел может иметь несколько исходных узлов.

3. Исходный узел в сетевой модели называется владельцем набора, а порожденный узел - членом набора.

4. Любой узел может быть одновременно и в роли исходного, и в роли порожденного.

5. В сетевой модели могут присутствовать связи: 1:1, 1:М, М:1, М:М.

Основной недостаток такой модели заключается в том, поиск информации - процесс не однозначный. Например, на рисунке 3.2 (первая модель) из узла с номером 1 в узел с номером 4 при поиске можно попасть разными путями:

1 - 2 - 4 или 1 - 3 - 4. Поэтому, появляется еще одна проблема, а именно, проблема определения оптимального поиска информации.

Реляционные модели данных

Один из самых естественных способов представления данных для пользователя - программиста - это двумерная таблица. Поэтому реляционную базу данных (РБД) можно представить в виде взаимосвязанных таблиц.

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

Таблица 2.1

Формальный реляционный термин	Неформальный эквивалент
Отношение Кортеж Кардинальное число Атрибут Значение атрибута Степень Первичный ключ Домен Схема отношения Тип данных	Таблица Строка или запись Количество строк Столбец или поле Значение поля в строке Количество столбцов Уникальный идентификатор Общая совокупность допустимых значений Строка заголовков столбцов таблицы Тип значений элементов таблицы

Рассмотрим, например, отношение "Служащий", таблица 2.2

Отношение (таблица) обладает следующими свойствами:

1. Каждый элемент таблицы представляет собой один элемент данных, повторяющиеся группы отсутствуют.

2. Все столбцы в таблице однородные (одинаковой природы).

3. Столбцам однозначно присвоены имена.

4. В таблице нет двух одинаковых строк.

5. Строки и столбцы могут просматриваться в любом порядке.

6. Каждый кортеж должен иметь ключ - идентификатор.

Реляционная БД - это база данных, воспринимаемая пользователем как набор нормализованных отношений разной степени. Таблица может быть представлена в виде отношения (relation): R(A1,A2,…An), где n - атрибуты отношения.

Любая структура данных может быть сведена к двумерным плоским файлам в форме двумерных таблиц.

На рис.2.5 приведен пример приведения древовидной структуры к реляционной, основной ключ (соответствующий корню) при этом включается в подчиненные отношения, получая их расширение:

Одним из самых важных характеристик отношения являются ключи. Рассмотрим их подробнее и дадим основные определения:

1. Первичный ключ - это один или несколько атрибутов, которые единственным образом идентифицируют каждую строку таблицы. Удаление какого-либо атрибута из сложного ключа нарушает идентификацию.

2. Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации называются возможными ключами. Любой из них может быть выбран первичным кличем. Например, в отношении "Студент" возможными ключами являются атрибуты:

Номер_зачетной_книжки или Номер_группы, ФИО.

Как правило, первичным ключом выбирается Номер_зачетной_книжки, т.к. он короче, а значит, им удобнее пользоваться и уменьшается возможность ошибки в ключе.

Ключи используются для:

- исключения дублирования кортежей;

- упорядочения кортежей, а, следовательно, сокращения времени обработки данных;

- организации связей между отношениями.

Связывание отношений

Рассмотрим пример организации связей между отношениями в РБД:

Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ.

В РБД должна обеспечиваться, так называемая, ссылочная целостность, т.е. каждому значению внешнего ключа должна соответствовать строка в связываемых таблицах.

При связывании двух отношений выделяют основное (R2 и R3) и дополнительное (подчиненное отношение). Логическое связывание производится с помощью ключа связи. Ключ связи - это один или несколько атрибутов (они могут быть ключевыми и обычными).

Связь - это установление соответствия атрибутов связи основного и дополнительного отношений. Между двумя отношениями могут быть связи: 1:1, 1:М, М:1, М:N.

Контроль целостности

Так как чаще всего используется связь 1:М, рассмотрим именно ее.

Контроль целостности для двух этих отношений (рис.2.6.) означает:

1. Каждому кортежу основного отношения соответствует 0(ноль) или более кортежей дополнительного отношения.

2. В дополнительном отношении нет кортежей, которые не имеют "родительских" кортежей в основном отношении.

3. Каждый кортеж дополнительного отношения имеет только один "родительский" кортеж в основном отношении.

Как правило, если в РБД установлена связь между отношениями, то СУБД автоматически отслеживает целостность.

Переход от ER модели к реляционной

Вернемся вновь к вопросам проектирования БД и рассмотрим методику перехода от ER модели к реляционной модели.

1. Каждой сущности ER модели ставится в соответствие отношение реляционной модели данных. При этом имена отношений и сущностей могут и не совпадать, например "Книга" в ER модели и "Books" в РБД.

2. Каждый атрибут сущности становится атрибутом отношения, возможно с другим именем. Для каждого атрибута отношения при этом определяется тип данных, допустимый для данного СУБД, обязательность или необязательность (NULL или NOT NULL) данного атрибута.

3. Первичный ключ сущности становится первичным ключом отношения.

4. В каждое подчиненное отношение добавляется набор атрибутов основного отношения, являющееся первичным ключем основного отношения. (внешний ключ).

Вернемся, к примеру ER модели "Библиотека" и представим связь между отношениями "Книга" и "Экземпляр".

3. Даталогическое проектирование

Даталогическое проектирование в РБД, называемое также логическим проектированием, - это построение схемы БД, т.е. совокупности схем отношений, которые адекватно отображают объекты предметной области и семантические связи между ними.

Цель логического проектирования РБД - построение такой ее схемы, в которой нет нежелательных связей между атрибутами, что может привести к избыточности информации и, в свою очередь, к увеличению времени обработки информации.

Классическая технология логического проектирования реляционных баз данных основана на теории нормализации отношений, разработанной американским математиком Е. Коддом. При этом проектирование - это последовательный переход от более низких нормальных форм к более высоким формам. Различают следующие нормальные формы: 1НФ, 2НФ, 3НФ, НФ Бойса-Кодда, 4НФ, 5НФ. На практике ограничиваются, как правило, приведением отношений к третьей нормальной форме (3НФ). В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи.

Нормализация отношений

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

Введем вначале некоторые понятия.

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

Определение 2. Отношение приведено к 1НФ, если все его атрибуты простые.

Рассмотрим процесс нормализации на примере отношения Сотрудник.

Табельный номер в этом отношении является первичным ключом. Атрибуты Таб. № ФИО, Оклад, Комната, Телефон являются простыми, а вот атрибут Дети - это соединение значений из двух доменов, т.е. - сложный. И, согласно определению 2, отношение R1 не приведено к 1НФ.

Если же посмотреть на эту таблицу с точки зрения ввода информации в компьютер, не понятно, как вводить, например, информацию о первом сотруднике: то ли только первую строчку (тогда будут потеряны Женя и Вася), то ли все три строки (тогда не ясно к кому относятся строчки с Женей и Васей). Все эти трудности возникают в связи с тем, что в отношении присутствуют сложные атрибуты. т.е. нарушена 1НФ.

Для приведения к 1НФ расширим первичный ключ R1 (его исходный первичный ключ - это Таб№). Добавим к первичному ключу одно из полей сложного атрибута, например, Имя_ребенка., и заполним таблицу следующим образом.

Отношение R2 приведено к 1НФ, все его атрибуты простые и ввод этой таблицы не вызовет никаких затруднений. Но у R2 есть недостатки, а именно:

1. Одна и та же информация дублируется многократно.

2. Для изменения информации по одному сотруднику приходится изменять несколько строк. Например, если увеличили зарплату сотрудникам, то для каждого сотрудника придется изменять столько строк, сколько у него детей.

3. Если у кого-то из сотрудников нет детей, то информация о нем вообще не попадет в базу данных, т.к. имя ребенка является частью составного первичного ключа.

Чтобы устранить эти недостатки, продолжим процесс нормализации. Но предварительно дадим некоторые определения.

Определение 3. Возможным ключом отношения является набор атрибутов отношения, который полностью и однозначно определяет значения всех остальных атрибутов отношения.

Отношение может иметь несколько возможных ключей, среди которых выбирается один, называемый затем первичным ключом отношения. Например, отношение Студент имеет два возможных ключа: ФИО и №_зач_книжки. Но, как правило, первичным ключом назначается атрибут №_зач_книжки.

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

Определение 5. Функциональная зависимость.

Пусть Х и У два атрибута некоторого отношения.

Говорят, что У функционально зависит от Х, если в любой момент времени каждому значению Х соответствует только одно значение У(Х. У).

Определение 6. Взаимно-независимые атрибуты - это атрибуты, которые функционально не зависят друг от друга.

Определение 7. Если в отношении существует несколько функциональных зависимостей, то каждый атрибут или несколько атрибутов, от которых зависит другой атрибут, называется детерминантом отношения.

Определение 8. Говорят, что не ключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от всего ключа, а не от какой-то его части.

В свете выше сказанного определим функциональные зависимости для нашего примера, т.е. отношения R2 (рис.3.1).

Как видим из рисунка, от составного ключа зависит только один не ключевой атрибут, а именно Возраст ребенка. Все же остальные не ключевые атрибуты зависят только от части ключа, от атрибута Таб №.

Рис.3.1. Функциональные зависимости отношения R2.

Определение 9. Отношение находится во 2НФ, если оно находится в 1НФ, и каждый его не ключевой атрибут функционально полно зависит от составного ключа.

Согласно данному определению, можем заметить нарушение 2НФ для отношения R2, т.к. не все не ключевые атрибуты функционально полно зависят от составного ключа.

Для приведения к 2НФ проведем декомпозицию (разделение) данного отношения на несколько отношений в зависимости от функциональных зависимостей. В результате получим следующие отношения:

Итак, получили два отношения, каждое из которых приведено ко 2НФ. Вернемся теперь к тем недостаткам отношения R2, которые были перечислены выше. Все они исчезли при приведении R2 ко 2НФ, т.е. при разделении R2 на два новых: R3 и R4.

1. Дублирование информации исчезло.

2. По каждому сотруднику вносятся изменения только в одну строчку.

3. Если даже у сотрудника нет детей, информация о нем все равно попадает в базу данных в таблицу R4.

Рассмотрим теперь подробнее отношение R4 . Номер телефона в этом отношении - это скорее характеристика комнаты, а не сотрудника.



Рис. 3.2. Функциональные зависимости отношения R4

По этой причине возникают следующие недостатки отношения R4:

1. Номер телефона будет многократно повторяться т.к. этот атрибут присутствует в строке для каждого сотрудника.

2. Изменение номера телефона в какой-либо комнате влечет за собой изменения в нескольких строчках таблицы (в зависимости от количества сотрудников в этой комнате).

3. Если в комнате, пусть временно, например, во время ремонта, никто не сидит, то сведения о комнате и номер телефона вообще не попадают в базу данных, т.к. для R4 ключом является Таб№ сотрудника.

Для устранения этих недостатков продолжим нормализацию отношения R4, но предварительно введем некоторые понятия.

Определение 10. Транзитивная зависимость. Пусть Х, У, Z - атрибуты одного отношения, и между ними существуют следующие функциональные зависимости:

Определение 11. Отношение находится в 3НФ, если оно находится во 2НФ и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.

В отношении же R4, нарушена 3НФ. Проведем декомпозицию R4, разделив его на два отношения, т.е. уберем транзитивную зависимость.

Разделив отношение R4 на два отношения R5 и R6, мы получили отношения в 3НФ и при этом устранили выше перечисленные недостатки.

Итак, наша база данных состоит из трех отношений:

R3: Дети(Таб№, Имя_ребенка, Возраст_ребенка)

R5:Сотрудник(Таб№, ФИО, Оклад, Комната)

R6:Комната(№комнаты, Телефон)

На практике, как правило, ограничиваются приведением отношений к 3НФ. Но иногда возникает необходимость и в приведении к более высоким нормальным формам.

Нормальная форма Бойса-Кодда

Отношение находится в нормальной форме Бойса - Кодда (НФБК) в том случае, если оно находится в 3НФ, и каждый детерминант отношения является возможным ключом отношения.

Напомним, что детерминант - это любой атрибут отношения, от которого полностью функционально зависит другой атрибут.

Рассмотрим пример отношения сдачи текущих экзаменов студентами:

Экзамены (№зачетки, Идент_номер, Дисциплина, Дата, Оценка).

В этом примере атрибут Идент_номер (Идентификационный номер) - это некий уникальный номер студента, введенный для электронного учета. Это отношение имеет два возможных ключа:

№зачетки, Дисциплина, Дата и Идент_номер, Дисциплина, Дата

Рассмотрим Функциональные зависимости в этом отношении:

Эти два варианта равнозначны. Просто в первом варианте за первичный ключ принят первый возможный ключ, а во втором - второй возможный ключ. Можно рассматривать любой из этих вариантов, мы остановимся на первом. №зачетки и Идент_номер взаимно определяют друг друга, т.е являются детерминантами, но возможными ключами не являются, т.к. каждый возможный ключ состоит из трех атрибутов. Т.е. по определению это отношение не является отношением в НФБК. Разобьём его на два отношения R1 и R2:

В отношении R2 №зачетки и Идент_номер являются детерминантами и в то же время являются возможными ключами, т.е. это отношение в НФБК.

Четвертая нормальная форма (4НФ)

Прежде чем перейти к рассмотрению 4НФ, введем следующее определение:

В отношении R(А,В,С) существует многозначная зависимость (multi valid dependence - MVD) том и только в том случае, если множество значений В, соответствующих паре значений А и С, зависят только от А и не зависят от С.

Здесь выделяется случай, когда одному значению атрибута соответствует устойчиво постоянное множество значений другого атрибута.

Рассмотрим отношение R:Сессия (№зачетки, №группы, Дисциплина), в котором присутствуют две MVD зависимости (табл.3.1):

1. №группы №зачетки, т.к. список студентов (№зачетки) зависит только от номера группы (№группы) и не зависит от дисциплин, сдаваемых в сессию (Дисциплина).

2. №группы Дисциплина, т.к. список сдаваемых дисциплин зависит от номера группы (№группы) и не зависит от списка студентов, обучающихся в данной группе.



Отметим недостатки отношения Сессия:

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

2. При изменении учебного плана, например, при добавлении только одной дисциплины Информатика, придется изменять столько кортежей, сколько студентов обучаются по этому плану;

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

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

Теорема Фейджина

Отношение R(А,В,С) можно спроецировать без потерь в отношения R1(А,В) и R2(А,С) том и только в том случае, когда в R существуют две MVD зависимости R.А R.В и R.А R.С.

Под проецированием при этом понимается декомпозиция (разделение) отношения на два отношения путем применения операции проекции. Исходное отношение из проекций полностью без избыточности и потерь восстанавливается путем естественного соединения проекций.

Определение: Отношение R находится в 4НФ том и только в том случае, когда в нем существует MVD зависимость R.А R.В, а все остальные атрибуты зависят только от А и не зависят от В.

Вернемся к нашему примеру R:Сессия. Это отношение удовлетворяет условиям теоремы Фейджина, что позволяет получить две проекции R1 и R2 из которых путем естественного соединения можно получить исходное отношение R.

Эти новые отношения находятся в 4НФ по определению, т.к. в каждом из них есть MVD зависимость R.А R.В, а других атрибутов просто нет.

Недостатки, которые были отмечены в исходном отношении R, устранились. Таким образом, вместо одного исходного отношения R мы получили два новых отношения R1 и R2 в 4НФ.

Исходное отношение R путем соединения только двух проекций без потерь или излишков не восстанавливается. Проверим это. Произведем соединение двух отношений R1 и R2, получим при этом отношение R4:

Размещено на Allbest.ru