Контрольная работа по базам данных заказать

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

Контрольная работа по базам данных заказать

Контрольная работа по базам данных заказатьОтветы на вопросы по заказу контрольной работы по базам данных:

Контрольная работа по базам данных заказать

Контрольная работа по базам данных заказатьСколько стоит помощь с контрольной работой?

  • Цена зависит от объёма, сложности и срочности. Присылайте любые задания по любым предметам - я изучу и оценю.

Контрольная работа по базам данных заказатьКакой срок выполнения контрольной работы?

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

Контрольная работа по базам данных заказатьЕсли требуется доработка, это бесплатно?

  • Доработка бесплатна. Срок выполнения от 1 до 2 дней.

Контрольная работа по базам данных заказатьМогу ли я не платить, если меня не устроит стоимость?

  • Оценка стоимости бесплатна.

Контрольная работа по базам данных заказатьКаким способом можно оплатить?

  • Можно оплатить любым способом: картой Visa / MasterCard, с баланса мобильного, google pay, apple pay, qiwi и т.д.

Контрольная работа по базам данных заказатьКакие у вас гарантии?

  • Если работу не зачли, и мы не смогли её исправить – верну полную стоимость заказа.

Контрольная работа по базам данных заказатьВ какое время я вам могу написать и прислать задание на выполнение?

  • Присылайте в любое время! Я стараюсь быть всегда онлайн.

Контрольная работа по базам данных заказать

Контрольная работа по базам данных заказатьНиже размещён теоретический и практический материал, который вам поможет разобраться в выполнении контрольной работы по предмету "База данных", если у вас есть желание и много свободного времени!

Контрольная работа по базам данных заказать

Содержание:

  1. Ответы на вопросы по заказу контрольной работы по базам данных:
  2. Введение в базы и банки данных
  3. Компоненты БнД
  4. Классификация моделей данных
  5. Иерархическая модель данных
  6. Реляционная модель данных
  7. Методология проектирования БД
  8. Даталогическое и физическое проектирование БД
  9. Проектирование БД методом нормальных форм
  10. Разработка базовой -модели. Алгоритм перехода к РМД
  11. Концептуальные и физические -модели
  12. Средства автоматизации проектирования
  13. Модели структурного проектирования
  14. SQL: функции и основные возможности; стандарты языка SQL
  15. SQL: команды определения и манипулирования данными
  16. Использование языка SQL в прикладных программах
  17. Интерфейсы программирования приложений (API)
  18. Протокол ODBC
  19. Протокол JDBC
  20. Фактографические и документальные БД
  21. Мультимедийные БД
  22. Защита информации в СУБД
  23. Средства защиты БД
  24. Технология оперативной обработки транзакций (OLTP -технология). XML - сервер.
  25. Механизм транзакций
  26. XML-сервер
  27. Классификация БД по способу доступа. Архитектура многопользовательских СУБД.
  28. Технология „клиент/сервер"
  29. Информационные хранилища. OLAP - технология.
  30. Основные элементы и операции OLAP
  31. Диалект SQL фирмы ORACLE
  32. База данных и модель данных
  33. СУБД
  34. Реляционный подход к моделированию данных
  35. Нормализация реляционной базы данных
  36. Ортогонализация отношений
  37. Объектно-реляционный подход к моделированию БД
  38. SQL
  39. Модели «Клиент-сервер». Модель сервера баз данных (DBS). Модель сервера приложений (AS).
  40. История SQL
  41. Диалект SQL в СУБД Oracle
  42. PL/SQL

Введение в базы и банки данных

Основные понятия:

Данные это статичные значения, которые сохраняются в таблицах базы данных. Ключевое слово в определении — «статичные».

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

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

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

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

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

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

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

Атрибут - это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

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

По этой ссылке вы сможете узнать как я помогаю с контрольными работами:

Помощь с контрольными работами

Администратор базы данных представляет собой лицо (или группу лиц), ответственное за общее управление системой базы данных.

Термин «база данных» был введен в 1963 г. в англоязычной литературе (data base), в 70-х гг. этот термин стали писать через дефис (data-base), а потом - одним словом (database). Имя автора этого термина не известно.

Историю развития баз данных можно разделить на три периода. Первый период - 60-е гг. - переходный. Появление самого понятия и нескольких первоначальных систем. В 1959 г. Мак-Гри предложил использовать файлы исходных данных. Файл, который введен в компьютер, становился общим, и его могли совместно использовать многие пользователи. Компьютеры обеспечивали доступ к данным. Мак-Гри разработал систему баз данных IMS фирмы IBM.

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

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

Свойства базы данных:

  1. Многоразовое использование: одни и те же данные могут использоваться многими пользователями.
  2. Простота обновления - возможность внесения изменений в базу с минимальными затратами.
  3. Быстрый поиск и получение необходимой информации по запросу.
  4. Уменьшение избыточности - новые задачи должны получать данные из существующей базы, а не путем их повторного ввода.
  5. Защита от несанкционированного доступа к данным.
  6. Максимальная независимость от прикладных программ: изменения в структуре базы данных не должны, по возможности, приводить к перезаписи пакета программ.
  7. Защита от уничтожения и искажения информации (некомпетентного пользователя, злоумышленных действий, сбоев и конфликтных ситуаций).

По этой ссылке вы сможете научиться оформлять контрольную работу:

Теоретическая контрольная работа примеры оформления

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

  1. Адекватность отражения предметной области: а) полнота данных; б) динамичность информационной модели; в) актуальность информации в данный момент времени.
  2. Возможность взаимодействия с пользователями различных категорий и в разных режимах.
  3. Обеспечение секретности данных, надежности, целостности, защита от случайного или целенаправленного разрушения базы данных.
  4. Обеспечение взаимной независимости программ и данных.
  5. Технологичность обработки данных.
  6. Совместимость компонентов базы данных.
  7. Простота изменения логической и физической структуры базы данных в целях повышения эффективности обработки информации.
  8. Способность к расширению и модификации.

Компоненты БнД

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

Информационный компонент

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

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

Программные средства БнД

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

Языковые сродства БнД

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

По этой ссылке вы сможете заказать контрольную работу:

Заказать контрольную работу

Языковые средства большинства современных СУБД относятся к языкам 4-го поколения (к 1-му поколению языков относят машинные языки, ко 2-му - символические языки ассемблера, к 3-му - алгоритмические языки типа PL, Cobol и т.п., которые в 1960-е гг. назывались языками высокого уровня, но уровень которых гораздо ниже, чем у языков 4-го поколения. Имеются еще и языки 5-го поколения, к которым относят языки систем искусственного интеллекта, например Prolog).

Технические средства БнД

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

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

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

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

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

Классификация моделей данных

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

Контрольная работа по базам данных заказать

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

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

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

Возможно вам пригодятся эти страницы:

Контрольная работа по политологии заказать

Контрольная работа по архитектуре заказать

Контрольная работа по геометрии заказать

Контрольная работа по гидравлике заказать

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

Контрольная работа по базам данных заказать

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

Контрольная работа по базам данных заказать

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

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

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

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

В этой модели объекты и взаимосвязи между ними представлены при помощи таблиц. Одна таблица представляет один объект и состоит из столбцов и строк. Каждая строка таблицы представляет собой одну запись, а каждый столбец - одно поле записей. Таблица обладает следующими свойствами:

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

Термины

Термины, которыми оперирует реляционная модель данных, имеют соответствующие "табличные" синонимы:

Контрольная работа по базам данных заказать

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

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

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

Свойства отношений

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

  1. Все строки таблицы должны быть уникальны, т.е. не может быть строк с одинаковыми первичными ключами.
  2. В таблице не должно быть столбцов с повторяющимися именами.
  3. Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов.
  4. Имена столбцов таблицы должны быть различны, а значения их простыми, т.е. недопустима группа значений в одном столбце одной строки.
  5. Порядок размещения строк в таблице может быть произвольным.

Двенадцать правил Кодда

Этим правилам, сформулированным Коддом, должна соответствовать реляционная СУБД:

  1. Правило информации.
  2. Правило гарантированного доступа.
  3. Правило поддержки недействительных значений.
  4. Правило динамического каталога, основанного на реляционной модели.
  5. Правило исчерпывающего подъязыка данных.
  6. Правило обновления представлений.
  7. Правило добавления, обновления и удаления.
  8. Правило независимости физических данных.
  9. Правило независимости логических данных. Ю.Правило независимости условий целостности.
  10. Правило независимости распространения.
  11. Правило единственности.

Преимущества реляционных моделей баз данных:

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

Методология проектирования БД

Основные понятия:

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

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

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

Основные цели проектирования:

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

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

  1. Системный анализ и словесное описание информационных объектов предметной области.
  2. Проектирование инфологической модели предметной области -частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах Е-модели.
  3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.
  4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

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

Даталогическое и физическое проектирование БД

Основные понятия:

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

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

Исходные данные для дат алогического проектирования

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

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

Результат даталогического проектирования

Конечным результатом даталогического проектирования является описание логической структуры базы данных на ЯОД. Однако если проектирование выполняется «вручную», то для большей наглядности сначала строится схематическое графическое изображение структуры базы данных. При этом должно быть обеспечено однозначное соответствие между конструкциями языка описания данных и графическими обозначениями информационных единиц и связей между ними. Графическое представление используется и при автоматизированном проектировании структуры базы данных как интерфейсное средство общения с проектировщиком, и при документировании проекта.

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

Физическое проектирование базы данных

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

В случае реляционной модели данных под этим подразумевается следующее:

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

Этапы методологии физического проектирования баз данных:

  1. Перенос глобальной логической модели данных в среду целевой СУБД.
  2. Проектирование основных отношений.
  3. Разработка способов получения производных данных.
  4. Реализация ограничений предметной области.
  5. Проектирование физического представления базы данных.
  6. Анализ транзакций.
  7. Выбор файловой структуры.
  8. Определение индексов.
  9. Определение требований к дисковой памяти.
  10. Проектирование пользовательских представлений.
  11. Разработка механизмов защиты.
  12. Обоснование необходимости введения контролируемой избыточности.
  13. Текущий контроль и настройка операционной системы.

Проектирование БД методом нормальных форм

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

Избыточное дублирование данных и аномалии

Следует различать простое (неизбыточное) и избыточное дублирование данных. Первое из них вполне естественно, второе может приводить к проблемам при обработке данных.

Избыточное дублирование данных создает проблемы при обработке кортежей отношения, названные Э. Коддом аномалиями обновления отношения. Он показал, что для некоторых отношений проблемы возникают при попытке удаления, добавления или редактировании их кортежей. Проблемы удаления и добавления кортежей, в принципе, снимаются в современных СУБД с появлением в них значений для полей таблиц типа Null - неопределенных значений.

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

Зависимости между атрибутами

Рассмотрим основные виды зависимостей между атрибутами отношений:

  • функциональные, многозначные и транзитивные.

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

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

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

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

Атрибут Контрольная работа по базам данных заказать зависит от атрибута Контрольная работа по базам данных заказать транзитивно, если для атрибутов Контрольная работа по базам данных заказать, Контрольная работа по базам данных заказать, Контрольная работа по базам данных заказать выполняются условия Контрольная работа по базам данных заказать и Контрольная работа по базам данных заказать, но обратная зависимость отсутствует. В отношении на рис. 5 транзитивной зависимостью связаны атрибуты:

Между атрибутами может иметь место многозначная зависимость.

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

Многозначные зависимости могут быть "один ко многим" Контрольная работа по базам данных заказать, "многие к одному" Контрольная работа по базам данных заказать или "многие ко многим" Контрольная работа по базам данных заказать, обозначаемые соответственно:

Контрольная работа по базам данных заказать

Выявление зависимостей между атрибутами

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

Процесс проектирования БД с использованием метода нормальных форм

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

Выделяют следующую последовательность нормальных форм:

  • первая нормальная форма (1НФ);
  • вторая нормальная форма (2НФ);
  • третья нормальная форма (ЗНФ);
  • усиленная третья нормальная форма, или нормальная форма Бойса-Кодда (БКНФ)
  • четвертая нормальная форма (4НФ);
  • пятая нормальная форма (5НФ).

Первая нормальная форма

Отношение находится в 1 НФ, если все его атрибуты являются простыми (имеют единственное значение). Исходное отношение строится таким образом, чтобы оно было в 1 НФ.

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

Основной операцией метода является операция проекции.

Вторая нормальная форма

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

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

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

Третья нормальная форма

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

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

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

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

Усиленная ЗНФ, или нормальная форма Бойса-Кодда (БКНФ).

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

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

  • частичных зависимостей неключевых атрибутов от ключа (2НФ);
  • транзитивных зависимостей неключевых атрибутов от ключа (ЗНФ);
  • зависимости ключей (атрибутов составных ключей) от неключевых атрибутов (БКНФ).

Разработка базовой -модели. Алгоритм перехода к РМД

Пример разработки простой Контрольная работа по базам данных заказать-модели

При разработке Контрольная работа по базам данных заказать-моделей мы должны получить следующую информацию о предметной области:

  1. Список сущностей предметной области.
  2. Список атрибутов сущностей.
  3. Описание взаимосвязей между сущностями.

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

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

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

  • Хранить информацию о покупателях.
  • Печатать накладные на отпущенные товары.
  • Следить за наличием товаров на складе.

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

  • Покупатель - явный кандидат на сущность.
  • Накладная - явный кандидат на сущность.
  • Товар - явный кандидат на сущность
  • (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
  • (?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

Контрольная работа по базам данных заказать

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

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

Контрольная работа по базам данных заказать

Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:

  • Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.
  • Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
  • Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.
  • Каждый склад имеет свое наименование.
  • Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
  • Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
  • Наименование покупателя - явная характеристика покупателя.
  • Адрес - явная характеристика покупателя
  • Банковские реквизиты - явная характеристика покупателя.
  • Наименование товара - явная характеристика товара.
  • (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
  • Единица измерения - явная характеристика товара.
  • Номер накладной - явная уникальная характеристика накладной.
  • Дата накладной - явная характеристика накладной.
  • (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
  • (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
  • (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
  • Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
  • Наименование склада - явная характеристика склада.

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

С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму:

Контрольная работа по базам данных заказать

Концептуальные и физические -модели

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

Контрольная работа по базам данных заказать

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

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

Средства автоматизации проектирования

Основные понятия:

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

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

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

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

Перспективная CASE-система

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

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

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

Осуществление процесса проектирования предполагает наличие возможностей:

определения основной модели прикладной задачи (бизнес-модели, обычно объектно-ориентированной) и правил ее поведения (бизнес-правил);

поддержки процесса проектирования с помощью библиотек, оснащенных средствами хранения, поиска и выбора элементов проектирования (объектов и правил);

создания пользовательского интерфейса и поддержания распространенных программных интерфейсов (поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т. п.);

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

Модели структурного проектирования

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

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

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

  • диаграммы сущность-связь или Контрольная работа по базам данных заказать-диаграммы - Entity-Relationship Diagrams (ERD) служат для наглядного представления схем баз данных;
  • диаграммы потоков данных - Data Flow Diagrams (DFD) служат для иерархического описания модели системы;
  • метод структурного анализа и проектирования - Structured Analysis and Design Technique (SADT), служащий для построения функциональной модели объекта;
  • схемы описания иерархии вход-обработка-выход - Hierarchy plus Processing - Output (HIPO) служат для описания реализуемых программой функций и циркулирующих внутри нее потоков данных;
  • диаграммы Варнье - Орра служат для описания иерархической структуры системы с выделением элементарных составных частей, выделением процессов и указанием потоков данных для каждого процесса.

Классификация CASE-средств При классификации CASE-средств используют следующие признаки:

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

Рекомендации по применению CASE-систем

Анализ характеристик и возможностей большинства современных CASE-систем позволяет сделать следующие выводы:

  1. CASE-системы позволяют ускорить и облегчить разработку, повысить качество создаваемых программ и информационных систем. Многие из CASE-систем имеют средства управления коллективной работой над проектом.
  2. CASE-системы особенно полезными оказываются на начальных этапах разработки Они являются не обязательной частью инструментария разработчика могут подменить средства проектирования и разработки в составе СУБД. Одной из основных причин для этого разнообразие средств разработки приложений, программно-аппаратных платформ и методологий проектирования.
  3. Предоставляемая многими CASE-системами возможность перехода от концептуальной модели БД к физической и обратно полезна для решения задач анализа, совершенствования и переноса приложений из среды одной "СУБД в другую.
  4. Большинство современных CASE-систем являются структурными, но благодаря некоторым преимуществам объектно-ориентированных систем последние приобретают все большую популярность, особенно при реализации сложных проектов.
  5. Современные CASE-системы ориентированы на квалифицированного пользователя, поскольку для их использования требуется знание теории проектирования баз данных. Так, например, для разработки структуры БД с помощью системы S-Designor информацию о проектируемой информационной системе нужно представить в виде ER-модели.

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

SQL: функции и основные возможности; стандарты языка SQL

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

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

Для реализации этих функций SQL включает три группы средств:

  • DDL (Data Definition Language) - язык определения данных;
  • DML (Data Manipulation Language) - язык манипулирования данными;
  • DCL (Data Control Language) - язык управления данными.

По стандарту ANSI DCL является частью DDL.

Синтаксис команд и примеры, рассмотренные далее соответствуют синтаксису СУБД Sybase.

В командах SQL не различаются прописные и строчные буквы (за исключением строчных литералов). Каждая команда заканчивается символом ';'. Значения параметров по умолчанию выделено подчеркиванием, например, ALL.

Примем следующие обозначения для описания синтаксиса:

{} - содержимое скобок рассматривается как единое целое для остальных символов;

| - заменяет слово ИЛИ;

[] - содержимое этих скобок является необязательным;

... - всё, что предшествует этим символам, может повторяться произвольное число раз;

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

История развития языка SQL

Работа была начата сразу после появления статью Э.Кодда в 1970 г. в лабораториях компании IBM для проверки возможностей реляционной модели.

Контрольная работа по базам данных заказать

СУБД System R - экспериментальная исследовательская система с языком SEQUEL (позже SQL), созданная IBM:

  • Полный реляционный язык БД
  • Операторы манипулирования БД
  • Средства определения и манипулирования схемой БД
  • Определение ограничений целостности
  • Определение представлений
  • Определение индексов
  • Авторизация доступа к отношениям и их полям
  • Точки сохранения транзакций и откаты

SQL в коммерческих реализациях:

  • 1979 - Oracle (Relation Software Inc.- Oracle corp.; 1981-1982 - DB2 (IBM), Ingres - CA-Openlngres (Relation Technology Inc. - Computer Associates)
  • 1984 - Informix (Informix Software); 1986 - Sybase (Sybase Corp.)
  • Реализован во всех коммерческих реляционных СУБД
  • Расширение модели транзакций (контрольные точки, многозвенные транзакций)

SQL: команды определения и манипулирования данными

Создание отношений

Создание нового отношения (таблицы) выполняется с помощью команды DDL CREATE TABLE. Команда CREATE TABLE используется для описания новой таблицы, её атрибутов (полей) и ограничений целостности. Упрощённый синтаксис этой команды:

CREATE TABLE <имя таблицы>

( {<имя поля> <тип данных> [(<размер>)]

[<ограничения целостности поля>...]} .,..

[, Ограничения целостности таблицы>.,..] );

Расшифровка элементов описания приведена в табл. 1.

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

Контрольная работа по базам данных заказать

Контрольная работа по базам данных заказать

К командам модификации данных (DML) относятся добавление, удаление и изменение (обновление) кортежа (записи).

INSERT - добавление записи в таблицу. Синтаксис:

INSERT INTO <имя таблицы> [(<имя поля>.,..)]

VALUES (<список выражений>) | <запрос>;

Под <запросом> подразумевается команда SELECT (см. ниже), результаты работы которой добавляются в указанную таблицу.

В предложении VALUES указываются выражения, порождающие значения атрибутов новой записи таблицы. Типы значений выражений должны соответствовать типам полей таблицы. Если значения устанавливаются не для всех полей или порядок значений не соответствует тому порядку полей, который был установлен при создании таблицы, то после имени таблицы в скобках приводится список полей в соответствии со списком значений. Если в списке полей не указано обязательное поле таблицы (not null), то ему будет присвоено значение по умолчанию (default), если оно определено в командах CREATE TABLE или ALTER TABLE.

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

DELETE - удаление записей из таблицы. Синтаксис этой команды:

delete from <имя таблицы> [ where <условие> ];

Внимание! Если в команде DELETE не указывать условие выбора записей, то все записи таблицы будут удалены без предупреждения и без запроса на подтверждение!

Извлечение данных из отношений

Извлечение данных из отношений выполняется с помощью команды SELECT (селекция). Эта команда не изменяет данные в БД.

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

SELECT * | { [ ALL | DISTINCT ] <список выбора>.,..}

FROM {<имя таблицы> [<алиас>] }.,..

[ WHERE <условие>]

[ GROUP BY {<имя поля> | <целое>}.,.. [ HAVING <условие>] ] [ ORDER BY {<имя поля> | <целое> [ AS С | DESC ] }.,..] [UNION [ALL] SELECT ...]; Расшифровка элементов описания приведена в табл. 2.

Контрольная работа по базам данных заказать

Контрольная работа по базам данных заказать

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

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

Рассмотрим основные предложения команды SELECT.

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

sal*0.87+bonus as salary

Если надо вывести все поля из тех отношений, к которым обращается данный запрос, можно указать символ * (если в отношениях нет полей с одинаковыми именами). В этом случае сначала будут выведены поля таблицы, стоящей первой в предложении FROM, затем - второй и т.д. Поля, относящиеся к одной таблице, будут выводиться в том порядке, в каком они были записаны при создании таблицы.

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

WHERE - содержит условия выбора отдельных записей.

GROUP BY - группирует записи по значению одного или нескольких полей. Каждой группе в результирующем отношении соответствует одна запись.

HAVING - позволяет указать условия выбора для групп записей. Может использоваться только после group by.

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

Порядок выполнения операции SELECT:

  1. Выбор из указанной таблицы тех записей, которые удовлетворяют условию отбора (where).
  2. Группировка полученных записей (group by).
  3. Выбор тех групп, которые удовлетворяют условию отбора (having).
  4. Сортировка записей в указанном порядке (order by).
  5. Извлечение из записей полей, заданных в списке выбора, и формирование результирующего отношения.

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

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

Операторы:

сравнения: =, >, <, >=, <=, <>; . логические: AND, OR, NOT.

Предикаты, используемые в запросах:

. IN:

field IN (список значений)

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

. BETWEEN:

field BETWEEN значение 1 AND значение2

- определяет, входит ли значение поля field в указанные границы. Если значение поля меньше, чем значение!, или больше, чем значение2, предикат возвращает "ложь".

. LIKE:

field LIKE 'образец'

- используется для поиска подстрок, применяется только в полям типа CHAR, VARCHAR. Возможно использование шаблонов: ' ' -один любой символ и '%' - произвольное количество символов (в т.ч., ни одного);

. IS [NOT] NULL:

field IS [NOT] NULL

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

Функции агрегирования:

  • COUNT - определяет в результате количество строк (записей) или значений поля, не являющихся NULL-значениями.
  • SUM - определяет арифметическую сумму значений указанного числового поля в результирующем множестве записей.
  • AVG - определяет среднее арифметическое значений указанного числового поля в результирующем множестве записей;
  • MAX, MIN - определяет максимальное (минимальное) значение указанного поля в результирующем множестве.

Правила уточнения использования агрегирующих функций:

SUM (distinct <поле>) - суммирование различных значений поля;

AVG (distinct <поле>) - среднее арифметическое разных значений поля;

COUNT (distinct <поле>) - подсчёт количества разных значений поля;

COUNT (<поле>) - подсчёт количества ненулевых значений поля;

COUNT (*) подсчёт количества строк в результате.

Работа с представлениями

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

Создание представления выполняется командой CREATE VIEW:

CREATE VIEW <имя представления> [(<имя столбца>.,..)]

AS <запрос>;

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

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

Удаление объектов базы данных Удаление объектов БД выполняется с помощью команды DROP.

DROP TABLE - удаление таблицы:

DROP TABLE <имя таблицы> [RESTRICT | CASCADE];

Таблица будет удалена без дополнительного запроса на подтверждение. При указании CASCADE вместе с таблицей каскадно удаляются все зависящие от неё объекты БД. Если указать RESTRICT, то при наличии зависимых от удаляемой таблицы объектов операция будет отменена.

DROP VIEW - удаление представления:

DROP VIEW <имя представления^ NULL-значения

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

Значение NULL не сравнимо ни с каким другим значением, даже со значением NULL. Тем не менее, предложение GROUP BY объединяет все MTLL-значения в одну группу, DISTINCT оставляет только одно NULL-значение, а функция AVG не учитывает N U LL- значения, и сумма значений поля делится на количество ненулевых значений.

Подзапросы

Подзапросы можно разделить на следующие группы в зависимости от возвращаемых результатов:

  • запросы, возвращающие от 0 до нескольких элементов (начинаются с оператора IN или модифицированного оператора сравнения);
  • запросы на существование (начинаются с оператора EXISTS);
  • запросы, возвращающие единственное значение (начинаются с немодифицированного оператора сравнения).

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

Рассмотрим операторы, которыми модифицируются операторы сравнения:

ALL - оператор, эквивалентный понятию "все". Например:

> ALL (< ALL) - больше (меньше) каждого значения элементов результирующего множества.

ANY (SOME) - оператор, эквивалентный понятию "любой".

= ANY - равно одному из значений элементов результирующего множества (эквивалентно использованию предиката IN).

> ANY (< ANY) - больше (меньше) любого значения элементов результирующего множества.

EXISTS - оператор, эквивалентный понятию "существует". Часто используется с логическим оператором NOT.

Если список, модифицированный оператором ALL, содержит M/LL-значение, то результирующий запрос будет пуст, т.к. нельзя сравнить никакое значение с N LJLL- значение м.

Выражение <>ANY(...) не эквивалентно NOT IN: оно выполняется всегда, кроме случаев NULL-значений.

Использование языка SQL в прикладных программах

Программный (встроенный) SQL

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

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

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

Решение этих проблем частично описано в стандарте SQL.

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

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

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

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

На настоящий момент используются три варианта встраивания запросов на языке SOLb прикладную программу (программного SQL): статический SQL, динамический SO 1м метод, основанный на различных интерфейсах программирования приложений( API ). Рассмотрим соответствующие варианты.

Статический SQL

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

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

Интерфейсы программирования приложений (API)

API (application programming interface) - интерфейс программирования приложений, представляют собой библиотеки функций, разработанные для обеспечения связи прикладной программы с СУБД посредством выполнения SQL-запросов. Прикладная программа вызывает специальные функции библиотеки для передачи в СУБД SQL-запроса в текстовом виде и для получения результатов выполнения запросов, а также различной служебной информации.

Применение подобного подхода приводит к тому, что программистам более не требуется изучать специальные наборы инструкций SQL, а необходимо лишь изучить специальную библиотеку функций. С учетом того, что механизм использования А Р1я вляется широко используемым и стандартным подходом (чего только стоит использование мощного аппарата Windows API), для специалистов нет ничего нового в изучении еще одной библиотеки, в данном случае - для общения с СУБД.

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

Протокол ODBC

ODBC (Open Database Connectivity - открытый доступ к базам данных) - разработанный компанией Microsoft универсальный интерфейс программирования приложений для доступа к базам данных.

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

Структура программного обеспечения ODBC:

  • интерфейс вызовов функций ODBC: это так называемый верхний уровень ODBC, содержащий API, который и используется непосредственно приложениями. Данный API реализован в виде библиотеки динамической компоновки D11 и входит в состав операционной системы Windows;
  • драйверы ODBC: это так называемый нижний уровень ODBC, содержащий набор драйверов для СУБД, поддерживающих протокол ODBC. В рамках технологии для каждой СУБД может быть разработан соответствующий ODBC-драйвер, который будет являться промежуточным звеном между прикладной программой и СУБД, транслируя вызовы функций СУБД в вызовы внутренних специализированных функций СУБД. Таким образом решается проблема стандартизации. Для многих современных СУБД существуют специализированные драйверы ODBC, отдельно устанавливаемые в операционную систему;
  • диспетчер драйверов ODBC: данный программный механизм представляет средний уровень ODBC, управляя процессом загрузки необходимых драйверов.

Протокол JDBC

JDBC (Java Database Connectivity) представляет собой API для выполнения SQL-запросов к базам данных из программ, написанных на языке Java.

С развитием глобальных сетей, в частности Интернета, и всех сопутствующих технологий стали появляться новые языки, специально предназначенные для работы в новых условиях. Одним из таких языков является язык программирования Java. В настоящее время Интернет-приложения занимают существенное место на рынке, работая в рамках 2-, 3- и многозвенной архитектуры. При этом значение языка Java как средства создания приложений, работающих с базами данных, существенно возрастает. Именно это и явилось одной из основных причин разработки нового программного интерфейса - JDBC. Первоначально интерфейс JDBC был разработан компанией Sun Microsystems, в настоящий момент этот API поддерживается всеми ведущими коммерческими СУБД.

Известно несколько различных версий JDBC. Так, версия 1.0 содержала некоторые средства доступа к данным:

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

Этот перечень определенным образом напоминает аналогичный функциональный аппарат протокола ODBC.

Версия JDBC 2.0 содержит существенные отличия. Так, вследствие увеличения возможностей интерфейса было проведено его идеологическое разделение на две основные части: Core API (основные возможности) и Extensions API (так называемые расширения). Возможности JDBC:

  • Пакетные операции. Программа на Java может осуществить обновление базы данных в пакетном режиме, т.е. одна функция JDBC может добавить в базу данных несколько записей, что положительно сказывается на производительности программ.
  • Курсоры с произвольным доступом. В JDBC 2.0 существует средство, позволяющее перемещаться по результатам запроса произвольным образом.
  • Обновляемые курсоры. В JDBC 2.0 курсоры, наряду с функцией возврата результата запроса, используются и при обновлении базы данных. Обновления производятся при добавлении или изменении одной из строк в результатах запроса.
  • Организация связного пула. Несколько программ на языке Java могут пользоваться совместным доступом к базе данных, уменьшая затраты на подключения к базе данных и отключения от нее. Данный перечень можно продолжить (распределенные транзакции, поддержка JNDI и т.д.).

Версия JDBC 3.0 содержит такие новации, как объектно-реляционные расширения SQL и улучшенные механизмы обработки транзакций. Архитектура JDBC берет свое начало от ODBC и в существенной части повторяет ее, поэтому схема выполнения программы на Java с использованием протокола JDBC для доступа к данным полностью аналогична схеме ODBC. В отличие от ODBC, драйверы JDBC подразделяются на четыре типа. Основные отличия между этими типами связаны с местонахождением API СУБД (на клиентской или серверной СУБД) и способом доступа к базе данных (через собственный API СУБД или через ODBC).

Библиотека DB-Library

Библиотека DB-Library реализует интерфейс программирования приложений для совместной работы с широко распространенной СУБД Microsoft SQL Server. Данная библиотека является весьма обширной и содержит более 100 функций.

Фактографические и документальные БД

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

Фактографические ИС используются не только для реализации справочных функций, но и для решения задач обработки данных. Под обработкой данных понимается специальный класс решаемых на ЭВМ задач, свяанных с вводом, хранением, сортировкой, отбором и группировкой записей данных однородкой структуры. Эти задачи предусматривают представление пользователям итоговых результатов обработки в виде отчетов табличной формы.

Различают:

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

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

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

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

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

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

Семантика (от греч. semantikos - обозначающий) — значения единиц языка.

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

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

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

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

Мультимедийные БД

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

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

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

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

Защита информации в СУБД

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

В целях защиты информации в БД на практике важнейшими являются следующие аспекты информационной безопасности (европейские критерии):

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

Средства защиты БД

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

К основным средствам защиты информации можно отнести следующие средства:

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

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

  • встроенные средства контроля значений данных в соответствии с типами;
  • повышения достоверности вводимых данных;
  • обеспечения целостности связей таблиц;
  • организации совместного использования объектов БД в сети.

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

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

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

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

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

Технология оперативной обработки транзакций (OLTP -технология). XML - сервер.

Основные понятия:

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

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

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

XML - сервер осуществляет взаимодействие с СУБД и обеспечивает первичный анализ загружаемых данных.

Механизм транзакций

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

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

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

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

Транзакция может быть неявной или явной. Неявная транзакция стартует автоматически, а по завершении также автоматически подтверждается или отменяется. Явной транзакцией управляет программист с использованием компонента Database и/или средств SQL.

Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД:

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

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

  • Подана команда COMMIT WORK (зафиксировать транзакцию).
  • Подана команда ROLLBACK WORK (откатить транзакцию).
  • Произошло отсоединение пользователя от СУБД.
  • Произошел сбой системы.

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

  • документальные;
  • фактографические.

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

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

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

XML-сервер

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

Контрольная работа по базам данных заказать

Задачи, решаемые XML-сервером:

  • организация удобного для программистов XML-интерфейса для доступа к СУБД (отпадает необходимость низкоуровнего взаимодействия с СУБД);
  • поддержка распределенных и разнородных баз данных (так как каждая СУБД обладает присущими только ей характеристиками, возникает проблема поддержки распределенных и разнородных баз данных. XML Server может учитывать конкретные реализации СУБД, обеспечивая "прозрачность" информационной системы для разработчиков);
  • промежуточное хранение данных (однократно запускаемые JAVA сервлеты и CGI процессы не могут хранить промежуточные данные в ОП. Соответственно XML server может устранить данный недостаток);
  • кэширование данных (повторные данные берутся непосредственно из XML Server без обращения к СУБД);
  • индексирование данных (частичный выбор данных, определенных пользователем).

Классификация БД по способу доступа. Архитектура многопользовательских СУБД.

Основные понятия:

Сервер - это программа, представляющая какие-то услуги другим программам. Примеры серверов - вебсервер Apache, серверы баз данных -MySQL, ORACLE, сетевые файловые системы и принтера Windows.

Клиент - это программа, использующая услугу, представляемую программой сервера. Примеры клиентов - MSIE (MS Internet Explorer), клиент ICQ.

Телеобработка

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

Файловый сервер

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

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

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

Технология „клиент/сервер"

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

Информационные хранилища. OLAP - технология.

Основные понятия:

Хранилище данных (Data Warehouse) - предметно - ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.

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

Архитектуры хранилищ данных

Несмотря на все разнообразие подходов к практической реализации систем поддержки принятия решений, основных видов хранилищ данных всего два: общекорпоративные хранилища данных (enterprise data warehouse) и киоски (или витрины) данных (data mart). Оба типа хранилищ имеют своих сторонников, а также свои сильные и слабые стороны.

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

Компоненты, используемые при построении хранилищ данных

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

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

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

Основные характеристики хранилищ данных:

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

Термин OLAP (On-Line Analytical Processing) служит для описания модели представления данных и соответственно технологии их обработки в хранилищах данных. В OLAP применяется многомерное представление агрегированных данных для обеспечения быстрого доступа к стратегически важной информации в целях углубленного анализа. Приложения OLAP должны обладать следующими основными свойствами:

  • многомерное представление данных;
  • поддержка сложных расчетов;
  • правильный учет фактора времени.

Основные элементы и операции OLAP

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

Факт - это числовая величина которая располагается в ячейках гиперкуба. Один OLAP-куб может обладать одним или несколькими показателями

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

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

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

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

В OLАР-системах поддерживаются следующие базовые операции:

  • поворот;
  • проекция. При проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону;
  • раскрытие (drill-down). Одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба;
  • свертка (roll-up/drill-up). Операция, обратная раскрытию;
  • сечение (slice-and-dice).

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

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

Диалект SQL фирмы ORACLE

Аннотация: Рассматриваются понятия, которые определяют диалект SQL, предлагаемый фирмой Oracle, в его нынешнем состоянии и формируют контекст употребления этого диалекта. В основном это реляционная модель данных и реляционное проектирование, а также стандартный SQL.

Ключевые слова: access group, BCNF, case-insensitive, data bank, e-wallet, grade, IEEE 754, lag, median, national characters, open group, pivot, RSX, SCN, time zone, аномалия обновления, вложенная транзакция, естественное внутреннее соединение, индекс первичного ключа, конфликт по данным, многомерное моделирование, наследование типов, ограничение внешнего ключа, параметр сеанса, реальная таблица, синтаксически корректный, табличное пространство, уникальный идентификатор объекта, фиксация транзакции, хозяин схемы, частичный результат, эквисоединение

Происхождение и объем диалекта SQL фирмы Oracle

Для успешного программирования в Oracle на SQL недостаточно знать сугубо формальное описание языка. Необходимо владеть более широким набором имеющих отношение к делу знаний. С этой целью ниже рассматривается цепочка понятий, подводящая к "диалекту SQL, предлагаемому фирмой Oracle". Она устроена следующим образом: база данных —> модель данных, СУБД; реляционная модель; язык запросов к данным и изменения данных —» SQL —> диалект SQL в Oracle.

База данных и модель данных

База данных

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

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

  1. "Обычно большое собрание данных, организованных для особо быстрого и удобного способа поиска и извлечения (например, из ЭВМ)".
  2. "Собрание структуризованных данных в ЭВМ, поддерживаемое СУБД, которая обеспечивает различным приложениям различный вид данных" (F. Pascal, Understanding Relational Databases with examples in SQL-92, New York, NY: John Whiley & Sons, 1993).
  3. "База данных — набор аксиом. Результат на запрос к базе есть теорема. Процесс вывода теоремы из аксиом есть доказательство. Доказательство осуществляется манипулированием символов по условленным математическим правилам. Доказательство [то есть результат запроса к базе] настолько же здраво и логично (consistent), насколько здравы и логичны правила" (Н. Darwen. The Duplicity of Duplicate Rows. Relational Database Writings 1989-1991, Reading, MA: Addison-Wesley, 1992).

Возможное обобщение этих и других определений:

"Совокупность всех данных некоторой прикладной области" [для использования в программных системах] (Филиппов В. И. Общее описание системы КОМПАС. // Автоматизация программирования. Москва: ВЦ АН СССР, 1989).

Существенные элементы в определениях БД:

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

Собственно БД. Организованные для долговременного хранения, обычно на внешнем носителе, данные общего пользования.

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

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

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

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

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

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

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

СУБД

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

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

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

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

Прочие, в том числе вытекающие из перечисленных (администрирование, статистика, распределение данных и т. д.).

Реляционный подход к моделированию данных

Наиболее существенное влияние на современные промышленные виды СУБД, включая Oracle, оказал реляционный подход к моделированию данных. Он основывается на использовании "реляционной теории", частью которой является "реляционная модель". Последняя берет свое начало со статьи своего основателя, Э. Кодда (Е. F. Codd), "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", опубликованной в IBM Research Report RJ599 в 1969 году. Впоследствии реляционная модель пережила всплеск интенсивного изучения и уточнения широким кругом специалистов, а в настоящее время она развивается главным образом усилиями К. Дейта (С. J. Date), сподвижника и коллеги Кодда во времена создания модели.

Выражение "модель данных" часто понимается в двух разных смыслах: как формальное описание некоторой конкретной предметной области и как инструмент для составления подобных описаний. Нужный смысл обычно приходится определять по контексту. Здесь выражение "реляционная модель данных" понимается как инструмент составления в БД конкретных описаний конкретных предметных областей.

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

"Тип данных" (type) — множество допустимых величин ("область определения") и операций. Для всех типов существуют операции сравнения и присвоения. Величинам не запрещено иметь структуру, например, объекта.

"Отношение" (relation) — множество атрибутов: уникальных имен с уточнением типа данных; плюс множество "наборов величин" ("рядов"), соответствующих атрибутам. Величины в наборах могут быть представлены только единичными значениями соответствующих атрибутам типов, то есть быть скалярами ("1-я нормальная форма").

"Переменная отношения" (relation variable) — переменная типа отношения конкретного вида, необходимое понятие для определения в базе данных действий по "обновлению отношений", "внесения изменений в данные". В нарушение точности и в силу поверхностно-ознакомительного характера настоящего материала далее вместо названия "переменная отношения" будет употребляться просто "отношение" (подобно вольному употреблению слова "целое" вместо "переменная целого типа").

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

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

"Операции" (operation) — множество общих действий над отношениями, дающих в результате опять-таки отношения ("замкнутость операций"). Используются для получения новых отношений в нуждах последующего моделирования или при извлечении из базы нужных данных. Перечень операций можно определять по-разному; в первых предложениях модели приводилось восемь операций (проекции, соединения, отбора и пр.), уже не минимальный набор, как компромисс между отсутствием избыточности и удобством употребления.

"Реляционная база данных" (relational database) — набор отношений.

"Тип данных" иногда называют "доменом" (domain), но иногда под "доменом" разумеют только "область определения" величин. "Набор величин" (tuple) по-русски иначе называют "кортежем" или "n-кой".

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

Если отказаться от определительного слова-кальки "реляционный", то термин "реляционная БД" можно перевести как "БД отношений" (точнее, "БД построенная посредством отношений"; отношений как инструмента, а не объекта моделирования: иначе исходный термин был бы relation database). Точно так же термин "реляционная модель" можно перевести как "модель отношений", то есть "система понятий для построения модели предметной области в виде набора отношений". По ряду причин, в том числе исторического и языкового характеров, этого не было в свое время сделано.

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

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

Нормализация реляционной базы данных

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

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

Пусть в отношении с данными о сотрудниках присутствуют и номер отдела сотрудника, и название отдела. Чтобы устранить зависимость между номером и названием отдела в отношении "сотрудники", достаточно оставить в нем только один из двух атрибутов (скорее всего, это будет "номер отдела"), создать отношение "отделы" с атрибутами "номер отдела" и "название", объявить в нем "номер отдела" ключом. "Номер отдела" в "сотрудниках" следует объявить внешним ключом, связав его с "номером отдела" из "отделов":

Избавляться от подобного рода функциональных зависимостей в отношениях можно, пока они не окажутся приведенными к "нормальной форме BCNF", Бойса-Кодда (Boyce-Codd); по праву первенства ее следовало бы назвать "нормальной формой Хита" (Heath). В таких отношениях, образно выражаясь, "каждое сведение относится к ключу, всему ключу (со всеми его атрибутами) и только к ключу" (в оригинальной фразе на английском вместо "сведения" дословно сказано "факт"), с тем добавлением, что ключей может быть несколько. Иными словами, в отношении, удовлетворяющем BCNF, произвол значений определяется только правилами ключа — возможно, внешнего ключа и типов атрибутов. Несколько менее строгий вариант BCNF именуется "3-й нормальной формой".

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

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

Нормализация отношений способствует:

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

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

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

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

Ортогонализация отношений

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

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

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

Объектно-реляционный подход к моделированию БД

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

Другие подходы к моделированию данных и другие типы СУБД

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

  1. Объектный подход.
  2. Объектно-реляционный подход
  3. Многомерное моделирование.
  4. Дедуктивное моделирование.

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

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

включением (во второй половине 90-х годов) в состав ведущих систем управления данными на основе SQL возможностей хранения объектных данных. Некоторые основы такого включения (например, приравнивание класса домену, или же объекта строке таблицы) остаются спорными. Фирма Oracle расширила табличные средства моделирования данных объектными возможностями в версии 8 своей СУБД, которую с этого времени стала именовать "объектно-реляционной". Поверхностное знакомство с объектными возможностями Oracle состоится в соответствующем разделе далее. Более плотное знакомство требует существенного увеличения объема материала.

Многомерное моделирование данных в базах данных имеет еще более давнюю, чем объектное, историю, уходящую корнями в 70-е годы. К его основным понятиям могут быть причислены: гиперкуб данных (или, по многомерной терминологии, "фактов"), измерения, иерархии, атрибуты. По большому счету (теоретически), оно не добавляет нового к тому, на что способны табличные СУБД, однако предлагает собственное представление данных и операции, что делает его удобным, а при соответствующей организации и эффективным в системах анализа данных. Фирма Oracle, купив в конце 90-х годов многомерную систему управления данными, встроила в свою СУБД основанную на функциональности купленной системы "машину OLAP" (on-line analytical processing). С версии 9 средства OLAP поставляются в составе Oracle Enterprise Edition. Они воплощены в двух исполнениях: унаследованном, предполагающим встроенную в СУБД самостоятельную систему хранения, и со сведением данных гиперкуба в привычную таблицу. Последнее исполнение рассчитано на работу с данными посредством SQL, слегка расширенного для этого случая фирмой-изготовителем. Это расширение специфично, несколько непоследовательно и далее не рассматривается.

Перечисленные подходы к моделированию данных существенно отличаются от реляционного тем, что не имеют математического обоснования, с вытекающими из этого последствиями:

отсутствием общепризнанной и экономной системы понятий,

невозможностью оценки создаваемых БД аналитическими средствами,

отсутствием методологии проектирования БД.

Из-за этого распространенность перечисленных подходов на практике ограничена.

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

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

Помимо указанного можно говорить о:

  • безмодельных БД;
  • слабоструктурированных БД.

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

Примером слабоструктурированных данных можно привести БД документов XML. Хранение документов XML в БД Oracle разрешила в версии 9.2 в двух вариантах: основном и продвинутом. Последний получил название XML DB, воплощая как бы "базу (XML) в базе (обычной)". Как и Oracle Text, XML DB поддерживается взаимодополняющее средствами SQL и встроенных программных пакетов, и по тем же причинам в этом материале она освещения не получила.

SQL

Что такое SQL?

Structured Query Language — язык, первоначально задумывавшийся как инструмент работы с реляционными базами данных, но с этой ролью в конце концов не справившийся.

Состоит из нескольких "подъязыков" разной функциональной направленности:

Запросы к данным БД (query language, QL) — выборка данных из таблиц предложением SELECT.

Язык манипулирования данными ("обработки данных"), ЯМД; Data Manipulation Language (DML) — изменение данных в существующих таблицах.

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

Язык определения данных (ЯОД); Data Definition Language (DDL) — например, создание таблиц и прочих объектов хранения или изменение их свойств.

Язык управления данными (ЯУД; data control language, DCL) — управление разрешением доступа к данным путем выдачи или изъятия полномочий командами GRANT и REVOKE, заданием в системе пользователей данных.

Единицами языка являются "команды", или "предложения" (commands, они же statements), или же "операторы". Слово "запрос" (query) иногда трактуют расширительно, понимая под ним любую команду SQL как "запрос к БД". С другой стороны, предложения SELECT часто обсуждают вместе с предложениями категории DML и в таких случаях иногда причисляют к последним.

Общие структурные свойства предложений DML и запросов можно охарактеризовать следующим образом:

Непроцедурность. Проявляется двояко:

Каждое предложение SQL является самодостаточным; предложения SQL не предназначены для процедурного описания действий.

Считается, что запрос к данным в SQL формулируется не указанием процедуры вычисления результата, а описанием свойств результата (statement буквально "утверждение"); СУБД же по указанным программистом свойствам автоматически строит последовательность действий, приводящую к требуемому результату. Современный SQL содержит некоторые отклонения от такой непроцедурное™.

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

По способу использования предложения SQL разделяются на две разновидности:

Диалоговый SQL. Вариант формулировок предложений языка (на выборку и изменение данных), предполагающий диалог программиста с СУБД по схеме "вопрос-ответ". Пример — работа с БД через программу Oracle SQL*Plus.

Встроенный SQL. Вариант формулировок языка, предполагающий размещение предложений SQL в программе (на С, С++, Cobol, Java, PL/SQL и проч.).

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

Модели «Клиент-сервер». Модель сервера баз данных (DBS). Модель сервера приложений (AS).

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

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

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

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

В соответствии с этим в любом приложении выделяются следующие логические компоненты: компонент представления (presentation), реализующий функции первой группы; прикладной компонент (business application), поддерживающий функции второй группы; компонент доступа к информационным ресурсам (resource manager), поддерживающий функции третьей группы, а также вводятся и уточняются соглашения о способах их взаимодействия (протокол взаимодействия).

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

Выделяются четыре подхода, реализованные в следующих моделях:

  • модель файлового сервера (File Server - FS);
  • модель доступа к удаленным данным (Remote Data Access - RDA);
  • модель сервера баз данных (Data Base Server - DBS);
  • модель сервера приложений (Application Server - AS).

Модель сервера баз данных (DBS) -реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle), (рис.5.3).

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

Контрольная работа по базам данных заказать

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

Достоинства DBS-модели:

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

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

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

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

Контрольная работа по базам данных заказать

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

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

Модели RDA и DBS опираются на двухзвенную схему разделения функций:

  • в RDA-модели прикладные функции отданы программе-клиенту
  • в DBS-модели ответственность за их выполнение берет на себя ядро СУБД.

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

История SQL

Первая версия SQL была предложена в 1973 году фирмой IBM под названием Sequel. В 1980 году этой же фирмой язык был воплощен уже под нынешним названием в проекте System R по построению прототипа реляционной СУБД (неформальную персонализированную историю и обсуждение последствий создания см. на

http://www.citforum.ru/database/digest/sqll.shtml). Успех System R дал начало многочисленным попыткам разных фирм воспроизвести эту систему, а вместе с ней SQL. Первый коммерческий результат такой деятельности принадлежит нынешней фирме Oracle. (Формулировки некоторых команд SQL в Oracle до сих пор напоминают о System R фирмы IBM.)

Для борьбы с несовместимостью воплощений SQL в разных системах язык вскоре оказался вовлечен в активную деятельность по стандартизации, проводившуюся разными организациями в разное время: в том числе Х/Ореп Group, SQL Access Group, FIPS, Госстандарт РФ. Сейчас действуют два комитета по стандартизации SQL: ANSI (в США) и ISO (международный), работающие синхронно.

Основные вехи стандартизации перечислены ниже:

  1. SQL-86 (1986/1987 гг.);
  2. SQL-89 (1989 г.; фактически SQL-86 с малыми добавками);
  3. SQL-92 (синонимы: SQL2, SQL92; 1992 г.):
  4. Вводный уровень (Entry Level),
  5. Переходный уровень (Transitional Level),
  6. Промежуточный уровень (Intermediate Level),
  7. Полный уровень (Full Compliance);
  8. SQL: 1999 (синонимы: SQL3, SQL-95, SQL1999, SQL-99, SQL99; главные дополнения — объектные возможности языка, хранимые процедуры):
  9. Основной уровень (Core),
  10. Расширенный уровень (Optional);
  11. SQL:2003 (пример дополнений — возможности XML). С этого момента очередные версии стандарта выходят не в полном объеме, как прежде, а в виде "дополнительных частей";
  12. SQL:2006 (развивает расширения, касающиеся XML, возникшие в SQL:2003);
  13. SQL:2008 (ряд частных дополнений, как, например, TRUNCATE TABLE или выдача первых N записей).

На основе SQL-92 построен ГОСТ Р ИСО/МЭК 9075-93.

Максимально достигнутый промышленными поставщиками уровень соответствия стандарту в настоящее время — Core SQL:2008, да и то с отклонениями. Он является продолжением (с расширениями и поправками) Core SQL: 1999, а тот — продолжением Entry Level SQL-92.

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

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

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

Далее по тексту ссылки на "стандарт SQL" и "стандарт ANSI/ISO" относятся фактически к стандартам SQL:20xx. Ссылки на SQL-92, SQL: 1999 и SQL:2003/8 уточняют время появления упоминаемого свойства стандарта SQL:20xx последней версии.

Исходное название — Sequel — происходит как сокращение от Structured English Query Language (так что некоторые ветераны программирования по сию пору произносят SQL как "сиквел"). Слово english в полном названии неслучайно: нынешний SQL замысливался в виде такого подмножества естественного языка, на котором потребитель данных мог бы обращаться к БД. Со временем метаморфоза произошла с "потребителем". Раньше полагали, что им будет конечный пользователь, а в наше время им оказался программист. Теперешний конечный пользователь как правило ничего не знает о SQL, работая с БД средствами графики или более высокого (по крайней мере архитектурно) уровня, построенными с помощью SQL, но уже программистом. Тем не менее, как и раньше, многие предложения на SQL действительно напоминают обычные человеческие высказывания. В этом таится большая опасность для программиста, так как на деле SQL — формальный язык (хоть и не самый сложный), который от человеческого отделяет пропасть. Выписывая предложение на SQL, программист нередко подсознательно пытается осмыслить написанное по-человечески, что иногда не страшно, но чаще совершенно искажает совершаемое СУБД на деле. Можно привести массу примеров, когда по-человечески воспринимаемая запись на SQL в действительности означает совсем иное. Заложенная когда-то в Sequel близость к формулировкам на английском языке вынуждает сегодняшнего программиста на SQL все время быть начеку. Показательно, что в расшифровке SQL (Structured Query Language) слово English выпало, но инерция развития языка сохраняется.

Диалект SQL в СУБД Oracle

СУБД Oracle версии 1 (под другим названием) появилась в 1978 г. и была написана на языке ассемблера для PDP-11 под ОС RSX. Oracle версии 2 появилась в 1979 г. и стала "первой коммерческой реляционной СУБД с использованием SQL", а в версии 3 ее ядро было переписано на языке С. С версии 8 фирма Oracle называет свою СУБД "объектно-реляционной". Фактически же это была и остается SQL-ориентированная СУБД, использующая собственный диалект SQL.

В силу истории происхождения диалект SQL фирмы Oracle естественно оценивать с трех сторон, определяющих одновременно и факторы влияния на существующий его вид:

  • реляционной теории,
  • стандартного SQL,
  • фирмы-разработчика.

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

Oracle "в значительной степени" (но не полностью и не в точности) поддерживает уровень Core SQL:2003, некоторые возможности уровня Optional Features SQL:2003 и набор собственных нестандартизованных свойств. Точное перечисление соответствия диалекта SQL Oracle стандарту приводится в документации по СУБД Oracle.

Некоторые собственные свойства диалекта SQL Oracle:

  • типы данных;
  • дополнительные к стандарту функции;
  • дополнительные конструкции SQL.

Объем диалекта SQL в Oracle по отношению к стандартам пояснен следующим рисунком.

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

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

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

PL/SQL

PL/SQL есть процедурный язык, встроенный в СУБД Oracle для возможности работать с хранимой в БД Oracle программной логикой. Наличие процедурного языка предусмотрено стандартом SQL (начиная с SQL: 1999), однако все собственные реализации разработчиков имеют, в отличие от случая с SQL, крайне мало общего между собой и с описаниями стандарта.

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

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

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

Операторы DML и SELECT из SQL могут употребляться на правах предложений языка PL/SQL. Это дает основание фирме Oracle иногда называть PL/SQL "процедурным расширением" SQL. Эффективность обработки СУБД таких операторов выше, чем у поступивших из внешней программы на общеупотребимом языке программирования.

Примечание:

Триггер (англ. trigger) — это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации данных: добавлением INSERT, удалением DELETE строки в заданной таблице, или изменением UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики. Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан. Все производимые им модификации данных рассматриваются как выполняемые в транзакции, в которой выполнено действие, вызвавшее срабатывание триггера. Соответственно, в случае обнаружения ошибки или нарушения целостности данных может произойти откат этой транзакции.