Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Билеты - Базы данных - файл 1.doc


Билеты - Базы данных
скачать (434 kb.)

Доступные файлы (1):

1.doc434kb.16.11.2011 03:56скачать

содержание

1.doc

  1   2   3   4
Вопросы для подготовки к экзамену


  1. Базы данных и файловые системы

  2. СУБД определение, функции

  3. СУБД определение, классификация

  4. БД основные определения, классификация

  5. Объекты базы данных

  6. Физическая структура БД в SQL Server

  7. Структурная часть реляционной модели

  8. Фундаментальные свойства отношений

  9. Реляционная алгебра Кодда

  10. Целостность реляционных данных, стратегии поддержания ссылочной целостности

  11. Этапы разработки баз данных

  12. Нормальные формы отношений

  13. Модель сущность-связь.

  14. Технология клиент-сервер

  15. Обзор MS SQL Server, клиентские приложения, системные таблицы

  16. Основы языка SQL, типы команд

  17. Основной синтаксис оператора SELECT

  18. Построение нетривиальных запросов с использованием оператора SELECT

  19. Операторы DML

  20. Операторы DDL

  21. Операторы DDL(определение структуры таблицы)

  22. Индексы

  23. Представления

  24. Сценарии и пакеты, управляющие конструкции SQL

  25. Хранимые процедуры

  26. Определяемые пользователем функции

  27. Триггеры

  28. Курсоры


1) БД и файловые системы

С самого начала развития вычислительной техники образовалось 2 направления ее использования.

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

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

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

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

- магнитные ленты

- барабаны не удовлетворяли требованиям: достаточный объем памяти, быстрота выполнения операций.

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

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

^ Недостатки при работе с файловой системой:

1. обеспечение авторизации доступа к файлам

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

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

2. режим многопользовательского доступа

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

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

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

^ 3. проблема синхронизации данных

Области применения файлов

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

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


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


^ Потребности информационных систем

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

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

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

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

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

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

Функции СУБД.

1. Непосредственное управление данными во внешней памяти

2. Управление буферами оперативной памяти

3. Управление транзакциями

4. Журнализация

5. Поддержка языков БД


Непосредственное управление данными во внешней памяти

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

^ Управление буферами оперативной памяти

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

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

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

С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций

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

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

Журнализация

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

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия - это полная копия БД к моменту начала заполнения журнала.

Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

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

Язык SQL включает язык определения данных, язык манипулирования данными, язык запросов, язык управления данными.

^ 2) СУБД определение, функции

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

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

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

^ Типовая организация СУБД

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

- компилятор языка SQL

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

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

^ Функции СУБД

1. управление данными во внешней памяти – обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей.

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

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

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

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

С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций

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

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

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

^ 5. поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language).

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

Язык SQL включает язык определения данных, язык манипулирования данными, язык запросов, язык управления данными.


^ 3) СУБД определение, классификация

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

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

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

^ Типовая организация СУБД

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

- компилятор языка SQL

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

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

^ Классификация СУБД

1. По модели данных

- иерархические

- сетевые

- реляционные

- объектно-ориентированные

- объектно-реляционные

- пост-реляционные

2. По степени распределенности

- локальные СУБД

- распределенные СУБД

3. По способу доступа к БД

- файл-серверные

- клиент-серверные

- встраеваемые


Иерархическая БД

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

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

Сетевая БД

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

Характерной особенностью РБД является структура, выполненная в виде таблиц. Строки таких таблиц соответствуют записям, столбцы - атрибутам (признакам хранимых данных).

^ Объектно-ориентированные базы данных (ООБД) появились совсем недавно как естественное развитие объектно-ориентированных языков программирования.

Данные представлены в виде объектов различных классов.

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

Для доступа к объектам, в каждой ООБД обычно предусматривается свой собственный язык, либо расширение другого языка. Пока еще ООБД недостаточно развиты и не представляют серьезной конкуренции SQL-серверам. Примеры, Cache, FastObjects,GemStone/S, Jasmine, ObjectStore и др

^ Объектно-реляционные БД

Разработчики многих реляционных БД включают в свои базы средства работы с объектными типами данных.

Такие базы данных получили название объектно-реляционных.

По этому пути, в частности, развивается и Oracle. Бывшая ранее чисто реляционной базой, Oracle начиная с 8 версии поддерживает возможность хранения и обработки объектов и безо всякой натяжки может быть отнесена к объектно-реляционному классу баз данных.

Пост-реляционными, часто называют многомерные базы данных.

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

Примеры, Cache, Teradata

^ Файл-серверные СУБД

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

На данный момент файл-серверные СУБД считаются устаревшими.

Примеры: Microsoft Access, Paradox, dBase.

^ Клиент-серверные СУБД

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

Примеры: Oracle, Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, PostgreSQL, MySQL, ЛИНТЕР, MDBS.

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

Примеры: OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.


^ 4) БД основные определения, классификация

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

Для работы с ними используется Система Управления Базой Данных (СУБД).

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

На основе БД создаются разнообразные информационные системы.

Классификация БД

1. В зависимости от размера БД и ее расположения можно выделить

- портативные БД, небольшие БД, находящихся в персональных компьютерах

- сетевые БД, крупные БД, расположенные на серверах, доступ к которым осуществляется по сети.

- распределенные БД и создаваемые на их основе информационные хранилища. БД, распределенные на нескольких серверах.

2. В зависимости от хранимых данных:

- фактографические БД: содержат краткие сведения об описываемых объектах, представленные в строго определенном формате.

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

- текстовая база данных - база данных, записи в которой содержат (главным образом) текст на естественном языке.

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

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

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

3. В зависимости от модели данных

- иерархическая состоит из объектов с указателями от родительских объектов к потомкам, соединяя вместе связанную информацию.

- сетевая

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

- многомерная (пост-реляционная)

- объектная

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

- объектно-реляционная

4. В зависимости от технологии хранения:

- БД во вторичной памяти (традиционные)

- БД в оперативной памяти (in-memory databases)

- БД в третичной памяти (tertiary databases)


^ 5) Объекты базы данных

Выделяют следующие объекты БД:

- таблицы

- типы данных (также определенные пользователем типы данных)

- ограничения

- значения по умолчанию

- правила

- ключи

- индексы

- представления

- хранимые процедуры

- определенные пользователем функции

- триггеры

- пользователи

- роли


Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования.

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

Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования.

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

^ Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа.

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

Таблица – отношение – множество кортежей, соответствующих схеме.

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

- cтроки; каждая строка (или запись) представляет собой совокупность атрибутов (свойств) конкретного экземпляра объекта;

- cтолбцы; каждый столбец (поле) представляет собой атрибут или совокупность атрибутов. Поле строки является минимальным элементом таблицы. Каждый столбец в таблице имеет определенное имя, тип данных и размер.

^ Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.

Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.

^ Схема БД (в структурном смысле) - это набор именованных схем отношений.

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения.

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

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

^ Ограничения целостности – механизм, обеспечивающий автоматический контроль соответствия данных установленным условиям (или ограничениям). Ограничения целостности имеют приоритет над триггерами, правилами и значениями по умолчанию. К ограничениям целостности относятся: ограничение на значение NULL, проверочные ограничения, ограничение уникальности (уникальный ключ), ограничение первичного ключа и ограничение внешнего ключа. Последние три ограничения тесно связаны с понятием ключей.

^ Значение по умолчания – самостоятельный объект базы данных, представляющий значение, которое будет присвоено элементу таблицы при вставке строки, если в команде вставки явно не указано значение для этого столбца.

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

^ Ключи – один из видов ограничений целостности данных. Различают первичный ключи и внешние ключи. Первичный ключ – набор атрибутов, значения которых однозначно определяют кортеж отношений (минимальный набор атрибутов).

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

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

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

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

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

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

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

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

Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлением определенных событий внутри реляционной базы данных.

Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности данных в базе данных.

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

Пользователи – лица, обладающие доступом к БД

Роли позволяют объединять пользователей в группы


6) Физическая структура базы данных

Физически база данных SQL Server 2000 хранится в самостоятельном, уникальном для каждой БД наборе файлов. Журнал транзакций и сами данные обязательно хранятся отдельно. Это повышает отказоустойчивость базы данных в случае сбоев системы.

^ Файлы данных и группы файлов

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

В SQL Server 2000 существует два типа файлов базы данных:

- файлы данных;

- файлы журнала транзакций.

Файлы данных (data file) предназначены для хранения информации, находящейся в таблицах базы данных. Кроме того, в этих файлах также размещены процедуры, ограничения, триггеры, индексы и другая информация.

В файлы журнала транзакций (transaction log file) SQL Server 2000 записывает информацию о ходе выполнения транзакций. В них размешается информация о состоянии данных перед началом транзакции, о выполняемых изменениях, блокированных ресурсах и другая сопутствующая информация.

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

Файлы данных бывают двух типов:

- Primary File (основной, или главный, файл);

- Secondary File (вторичный, или дополнительный, файл).

Каждая база данных имеет один и только один основной или главный файл (Primary File). Если база данных включает в себя только один файл данных, то этот файл будет основным. Основной файл предназначен для хранения всех системных таблиц, присутствующих в любой базе данных. В основном файле хранится информация о структуре базы данных, созданных в ней объектах, параметрах дополнительных файлов и файлов журнала транзакций. По умолчанию основному файлу базы данных присваивается расширение mdf (Master Data File).

В отличие от основного файла база данных может содержать множество вторичных или дополнительных файлов (Secondary File) или не содержать их вовсе. В дополнительных файлах может храниться только пользовательская информация. Хранение любой системной информации не допускается. В ходе эксплуатации базы данных администратор может добавлять новые или удалять уже существующие дополнительные файлы.

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

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

Каждый файл, используемый в базе данных, имеет два имени:

- Logical File Name – логическое имя файла, которое используется в командах Transact-SQL при ссылке на конкретный файл;

- OS File Name – имя файла в операционной системе, которое используется для обращения к файлу в операционной системе.

Сложные базы данных могут иметь несколько файлов для данных и для журнала транзакций. В этом случае файлы БД объединяются в группы для упрощения администрирования базы данных. SQL Server 2000 обеспечивает создание групп следующих трех типов:

- Primary File Group – основная группа файлов, которая включает первичный файл и все файлы, не включенные в другие группы, база данных может иметь только одну основную группу файлов;

- User-defined File Group – пользовательская группа файлов, создаваемая командой CREATE DATEBASE или командой ALTER DATABASE, если в них используется параметр FILEGROUP, в базе данных можно создать несколько пользовательских групп файлов с произвольным набором файлов;

- Default File Group – группа файлов по умолчанию, в качестве которой назначается одна из групп файлов, созданных в базе данных. Только одна группа файлов может быть группой по умолчанию. Если не указано явно, группой по умолчанию становится основная группа. Если при создании объекта базы данных не указано явно, к какой группе файлов он будет принадлежать, то этот объект создается в группе файлов по умолчанию.

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

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

^ 7) Структурная часть реляционной модели

Хотя понятие реляционной модели данных первым ввел основоположник реляционного подхода Эдгар Кодд, наиболее распространенная трактовка реляционной модели данных принадлежит известному популяризатору идей Кодда Кристоферу Дейту

Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода:

- структурной части,

- манипуляционной части,

- целостной части.


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


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

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


^ Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.


Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.


Схема БД (в структурном смысле) - это набор именованных схем отношений.


Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения.

^ Кортеж - это набор именованных значений заданного типа.


Отношение - это множество кортежей, соответствующих одной схеме отношения (аналог – таблица).

^ 8) Фундаментальные свойства отношений

Отношение - это множество кортежей, соответствующих одной схеме отношения (аналог – таблица).

Фундаментальные свойства отношений:

1. Отсутствие кортежей-дубликатов

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

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

Для каждого отношения по крайней мере полный набор его атрибутов обладает этим свойством.

2. Отсутствие упорядоченности кортежей

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

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

3. Отсутствие упорядоченности атрибутов

Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}.

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

4. Атомарность значений атрибутов

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

^ 9) Реляционная алгебра Кодда

Реляционная алгебра Кодда включает в себя теоретико-множественные операторы и специальные реляционные операторы.

Теоретико-множественные операторы

1. Объединение – отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих или A, или B, или обоим отношениям. (A UNION B)

2. Пересечение - отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих одновременно обоим отношениям A и B. (A INTERSECT B)

3. Вычитание - отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих отношению A и не принадлежащих отношению B. (A MINUS B)

4. Декартово произведение отношение (A1, A2, …, Am, B1, B2, …, Bm), заголовок которого является сцеплением заголовков отношений A(A1, A2, …, Am) и B(B1, B2, …, Bm), а тело состоит из кортежей, являющихся сцеплением кортежей отношений A и B: (a1, a2, …, am, b1, b2, …, bm), таких, что (a1, a2, …, am)∈ A, (b1, b2, …, bm)∈ B. Т.е. каждый кортеж первого отношения объединяется с каждым кортежем второго отношения. (A TIMES B)

^ Специальные реляционные операторы

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

2. Проекция – отношение, кортежи которого являются соответствующими подмножествами отношения операнда.

Отношение с заголовком (X, Y, …, Z) и телом, содержащим множество кортежей вида (x, y, …, z), таких, для которых в отношении A найдутся кортежи со значением атрибута X равным x, значением атрибута Y равным y, …, значением атрибута Z равным z. При выполнении проекции выделяется «вертикальная» вырезка отношения-операнда с естественным уничтожением потенциально возникающих кортежей-дубликатов.

A[X, Y, …, Z] или PROJECT A {x, y, …, z}

3. Соединение – отношение, кортежи которого производятся путем объединения кортежей первого и второго отношения и удовлетворяют некому условию. ((A TIMES B) WHERE С = A JOIN B WHERE С

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

4. Реляционное деление - отношение с заголовком (X1, X2, …, Xn) и телом, содержащим множество кортежей (x1, x2, …, xn), таких, что для всех кортежей (y1, y2, …, ym) ∈ B в отношении A(X1, X2, …, Xn, Y1, Y2, …, Ym) найдется кортеж (x1, x2, …, xn, y1, y2, …, ym). (A DIVIDEBY B)


^ Зависимость реляционных операторов

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

^ 1. Оператор соединения

Оператор соединения определяется через операторы декартового произведения и выборки следующим образом: (A TIMES B) WHERE X=Y где X и Y атрибуты соответственно отношений A и B с первоначально равными именами.

^ 2. Оператор пересечения

Оператор пересечения выражается через вычитание следующим образом: A INTERSECT B = A MINUS (A MINUS B)

3. Оператор деления

Оператор деления выражается через операторы вычитания, декартового произведения и проекции следующим образом: A DIVIDEBY B = A[X] MINUS ((A[X] TIMES B) MINUS A)[X]


^ Примитивные реляционные операторы

Оставшиеся реляционные операторы (объединение, вычитание, декартово произведение, выборка, проекция) являются примитивными операторами — их нельзя выразить друг через друга.

^ 1. Оператор декартового произведения

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

^ 2. Оператор проекции

Оператор проекции — единственный оператор, уменьшающий количество атрибутов, поэтому его нельзя выразить через объединение, вычитание, декартово произведение, выборку.

^ 3. Оператор выборки

Оператор выборки — единственный оператор, позволяющий проводить сравнения по атрибутам отношения, поэтому его нельзя выразить через объединение, вычитание, декартово произведение, проекцию.

^ 4. Операторы объединения и вычитания

10) Целостность реляционных данных, стратегии поддержания ссылочной целостности

Целостность реляционных данных фиксирует два базовых требования целостности:

- требование целостности сущности

- требование целостности внешних ключей


^ Целостность сущности

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


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

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


^ Правило целостности внешних ключей

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


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

- вставка

- обновление

- удаление кортежей в отношениях.

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

^ Для родительского отношения:

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

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

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

^ Для дочернего отношения:

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

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

3. Удаление кортежа в дочернем отношении. При удалении кортежа в дочернем отношении ссылочная целостность не нарушается.

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

1. Обновление кортежа в родительском отношении.

2. Удаление кортежа в родительском отношении.

3. Вставка кортежа в дочернее отношение.

4. Обновление кортежа в дочернем отношении.


Существуют две основные стратегии поддержания ссылочной целостности:

^ RESTRICT (ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к нарушению ссылочной целостности.

CASCADE (КАСКАДИРОВАТЬ) - разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других отношениях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении.


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


Дополнительные стратегии:

^ SET NULL (УСТАНОВИТЬ В NULL) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на null-значения.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию.

^ IGNORE (ИГНОРИРОВАТЬ) - выполнять операции, не обращая внимания на нарушения ссылочной целостности.


11) Этапы разработки БД

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

1. Сама предметная область

2. Модель предметной области

3. Логическая модель данных

4. Физическая модель данных

5. Собственно база данных и приложения


Предметная область - это часть реального мира, данные о которой мы хотим отразить в базе данных.

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


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

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

Более эффективны описания предметной области, выполненные при помощи специализированных графических нотаций. Одной из методик описания предметной области является методика объектно-ориентированного анализа UML.

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

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


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

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

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

Логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных.

Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).


^ Физическая модель данных описывает данные средствами конкретной СУБД.

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

Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД.

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


^ 12) Нормальные формы отношений

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

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

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

^ Функциональные зависимости

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

Пусть R - отношение. Множество атрибутов Y функционально зависимо от множества атрибутов X (X функционально определяет Y) тогда и только тогда, когда для любого состояния отношения R для любых кортежей r1,r2R из того, что r1X=r2X следует что r1Y=r2Y (т.е. во всех кортежах, имеющих одинаковые значения атрибутов X, значения атрибутов Y также совпадают в любом состоянии отношения R). Символически функциональная зависимость записывается XY

Множество атрибутов X называется детерминантом функциональной зависимости, а множество атрибутов Y называется зависимой частью.

Замечание. Если атрибуты X составляют потенциальный ключ отношения R, то любой атрибут отношения R функционально зависит от X.

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


^ Типы нормальных форм

Первая нормальная форма (1НФ) - это обычное отношение. Любое отношение автоматически уже находится в 1НФ.

Свойства отношений (это и будут свойства 1НФ):

- в отношении нет одинаковых кортежей.

- кортежи не упорядочены.

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

- все значения атрибутов атомарны.

^ Вторая нормальная форма (2НФ)

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

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

Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2НФ.

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


^ Третья нормальная форма (3НФ)

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

Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.

Нормализация: неключевые атрибуты, которые являются зависимыми, выносятся в отдельное отношение.

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

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

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

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

Отношение находится в 4НФ, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей, то есть, отношение находится в 4NF, если все ее многозначные зависимости являются функциональными.

^ Пятая нормальная форма (5НФ)

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


^ Алгоритм нормализации

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

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

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


^ 13) Модель сущность-связь

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

Сущность – класс однотипных объектов.

Атрибут сущности – именованная характеристика, являющаяся некоторым свойством сущности.

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

Связь – некоторая ассоциация между двумя сущностями:

- один-к-одному

- один-ко-многим

-много-ко-многим

^ Модальности связи:

- может

- должен


Модель Сущность-Связь (ER-модель) (англ. entity-relationship model или entity-relationship diagram) — это модель данных, позволяющая описывать концептуальные схемы. Она предоставляет графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является средством описания моделей данных.


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


ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest).


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


Существует несколько графических нотаций описания ER-диаграм (несколько похожих ER-моделей данных). Есть несколько типичных примеров использования ER-модели данных: IDEF1x (ICAM DEFinition Language) и dimensional modelling.-0

^ 14) Технология "клиент-сервер"

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

Какая-либо определенная архитектура может быть идеальной только для конкретной задачи.

Не возможно найти единственное правильное решение для всех возможных систем.

Существует три группы сервисов:

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

^ Business Services (Бизнес-сервисы). Это группа отвечает за различные бизнес-правила. Примером бизнес-сервисов, может быть сервис, который связывается с компанией кредитной карты клиента, чтобы подтвердить покупку по кредитной карте.

^ Data services (Сервисы данных). Все сервисы данного типа отвечают за хранение и поиск данных. Сервисы данных следят за выполнением правил целостности данных (например, объем товарно-материальных запасов не может быть меньше нуля), но в то же время не обращают внимания на то, откуда пришло подтверждение кредитной карты. (Здесь и находится SQL Server.)

^ Одноуровневые (хост) системы

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

Преимущества:

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

- такие системы обладают исключительной надежностью. Можно найти универсальные машины, которые не имели ни одного сбоя в течение нескольких лет

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

Недостатки:

- очень дорогое аппаратное обеспечение.

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

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

^ Двухуровневая архитектура (клиент-сервер)

Клиент-сервер (англ. Client-server) — сетевая архитектура, в которой устройства являются либо клиентами, либо серверами.

Клиентом (front end) является запрашивающая машина (обычно ПК), сервером (back end) — машина, которая отвечает на запрос. Оба термина (клиент и сервер) могут применяться как к физическим устройствам, так и к программному обеспечению.

Двухуровневые или клиент-серверные системы начали завоевывать популярность в начале 90-х.

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

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

- клиентоцентрическая (Client-centric - разумный клиент)

- сервероцентрическая (server-centric — разумный сервер).


^ Клиентоцентрическая версия клиент-серверной архитектуры была основана на двух основных посылках:

- персональные компьютеры достаточно дешевы (это явилось основной движущей силой развития клиент-серверной технологии);

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

В такой системе на сервере по возможности исполнялись только сервисы данных. А бизнес-сервисы и пользовательский интерфейс исполнялись на клиенте. Таким образом, объем работы распределялся между клиентом и сервером. Каждый компьютер делал свою долю.

Преимущества:

- распределяет объем работы между большим количеством сравнительно дешевых клиентов.

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

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

Недостатки:

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

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

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


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

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

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

Преимущества:

- некоторые обновления можно делать непосредственно на сервере.

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

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

Недостатки:

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

- продолжительные и трудоемкие задания одного из клиентов влияют на возможность использования ресурсов сервера всеми остальными клиентами.

- цена больших серверов растет экспоненциально. Некоторые из них сравнимы по цене с хост-системами.


^ Трехуровневая архитектура

Трехуровневая модель и близкая ей N-уровневая являются наиболее перспективными на сегодняшний день.

В этой модели все три уровня сервисов рассматриваются как разделенные и логически независимые.

Клиенты отвечают только за пользовательский интерфейс, так же как это имеет место в сервероцентрической клиент-серверной модели.

Отличие состоит в том, что бизнес-сервисы и сервисы данных тоже логически разделены.

Такое представление делает независимыми друг от друга логическую и физическую модели.

Преимущества:

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

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

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

- предусматривается (фактически поощряется) разработка систем на основе компонентов, что может увеличить степень повторного использования.

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

Недостатки:

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

- возникает острая необходимость в системе безопасности и инфраструктуре.

- неработоспособность сервера может сделать неработоспособной сеть.

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

- высокая стоимость оборудования.

^ 15) Обзор MS SQL Server, клиентские приложения, системные таблицы

SQL-сервер - сервер для управления реляционными БД.

Microsoft SQL Server 2000 - это система управления базами данных и анализа, предназначенная для быстрой разработки современных масштабируемых бизнес-приложений, систем электронной коммерции и информационных хранилищ; мощная СУБД, в полной мере отвечающая потребностям современных сложных систем типа клиент/сервер.

Масштабируемость

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


В сервер SQL Server 2000 включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения.

Кроме того, SQL Server 2000 полностью использует все возможности операционной системы Windows 2000, включая поддержку до 32 процессоров и 64 ГБ ОЗУ.

SQL Server 2000 работает с базами данных в OLTP-окружении (on-line transaction processing – оперативная обработка транзакций) и в окружении OLAP(on- line analytical processing аналитическая обработка в реальном времени)

Существует семь различных редакций сервера SQL 2000:

- Enterprise Edition – эта редакция является полной версией сервера SQL.

- Standard Edition – эта редакция разработана для малых и средних предприятий.

- Personal Edition – эта редакция основывается на Standard Edition, но оптимизирована для индивидуального использования.

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

- Enterprise Evaluation Edition – такая же как Enterprise Edition, но имеющая лицензию для «демонстрации, тестирования, изучения и оценки» и имеет 120-дневное ограничение использования.

- Windows CE Edition – эта редакция разработана для использования на устройствах, работающих под Windows CE.

- Desktop Engine (MSDE) – эта редакция представляет из себя только процессор базы данных сервера SQL 2000.


Службы SQL Server

^ 1. MSSQL Server Service - управление базами данных, обработка транзакций и запросов, обеспечение целостности данных.

2. SQLServerAgent Service - выполнение заданий по расписанию, создание и управление предупреждений (alerts) b операторов.

^ 3. Microsoft Distributed Transaction Coordinator (координатор распределенных транзакций) управление распределенными транзакциями.

4. Microsoft Search - полнотекстовый поиск


Визуальные средства администрирования:

1. SQL Server Service Manager - диспетчер служб SQL Server

^ 2. SQL Server Enterprise Manager - позволяет управлять несколькими серверами баз данных с помощью одного интерфейса

3. SQL Query Analyzer (координатор распределенных транзакций) управление распределенными транзакциями.

^ 4. SQL Server Network Utility позволяет конфигурировать подключения в клиентской части, узнать версию используемых сетевых библиотек

5. SQL Profiler – графическое средство отображения активности выбранного сервера.


Сопутствующие продукты SQL Server

^ 1. Microsoft English Query - инструмент, позволяющий преобразовать фразу на английском языке в набор операторов SQL.

2. Службы анализа данных позволяют создать базы данных OLAP, используемые для выполнения многомерного анализа информации.

^ 3. Утилиты командной строки

BCP программа массового копирования

ISQL – позволяет выполнять запросы с командной строки (использует DB-library для взаимодействия SQL Server)

OSQL – позволяет выполнять запросы с командной строки (использует ODBC для взаимодействия SQL Server)


^ Типы баз данных в SQL Server

В процессе установки SQL Server создаются системные базы данных master, model, tempdb, msdb, distribution и две пользовательские базы данных в качестве примера Northwind и pubs.


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

2. Model является моделью, по которой создается новая база данных

3. Tempdb содержит временные объекты

4. Msdb содержит системные задачи SQL Agent

5. Distribution содержит историю и транзакции данных, используемых при репликации


16) Основы языка SQL, типы команд

SQL (англ. Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.

SQL основывается на реляционной алгебре.

^ Основные категории команд языка SQL:

- DDL (Data Definition Language) – язык определения данных. Основными командами языка DDL являются следующие: CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX, ALTER INDEX, DROP INDEX.

- DML (Data Manipulation Language) – язык манипулирования данными. Основными командами языка DML являются следующие: INSERT, UPDATE, DELETE.

- DQL (Data Query Language) – язык запросов. Единственная команда языка DQL: SELECT.

- DCL – язык управления данными. Команды управления данными следующие: GRANT, REVOKE

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

- команды управления транзакциями. Существуют следующие команды, позволяющие управлять транзакциями базы данных: COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION.

^ Запись SQL-операторов

Оператор SQL состоит из зарезервированных слов, а также из слов, определяемых пользователем.

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

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

Стандарт SQL задает набор символов, который используется по умолчанию, – он включает строчные и прописные буквы латинского алфавита (A-Z, a-z), цифры (0-9) и символ подчеркивания (_).

На формат идентификатора накладываются следующие ограничения:

- идентификатор может иметь длину до 128 символов;

- идентификатор должен начинаться с буквы;

- идентификатор не может содержать пробелы.


Символ

Обозначение

::=

равно по определению

|

необходимость выбора одного из нескольких значений

<…>

описанная с помощью метаязыка структура языка

{…}

обязательный выбор некоторой конструкции из списка

[…]

необязательный выбор некоторой конструкции из списка

[,…n]

необязательная возможность повторения конструкции от нуля до нескольких раз
  1   2   3   4



Скачать файл (434 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации