рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Среда Delphi широко известна и не вызывает дополнительных трудностей при изучении и использовании

Среда Delphi широко известна и не вызывает дополнительных трудностей при изучении и использовании - раздел Программирование, Введение   В...

Введение

 

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

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

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

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

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

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

 

История создания баз данных

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

Модели данных СУБД

Коцептуальной моделью данных в БД называют глобальное логическое описание данных. Структуры данных коцептуальной модели влияют на все характеристики… · языки описания данных; · языки запросов;

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

 

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

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

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

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

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

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

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

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

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.

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

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

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

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

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

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

Двенадцать правил Кодда для реляционных СУБД

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

Нормализация таблиц БД. Первая, вторая и третья нормальные формы

При проектировании структуры БД естественным желанием бывает минимизировать количество таблиц, а в идеальном случае сосредоточить все данные в одной… К 1970 году были введены первая, вторая и третья НФ. В 1974 году были сделаны… В 1976 году были введены четвертая и пятая НФ. Если четвертая НФ имеет некоторое практическое значение, то пятая НФ в…

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

Пусть в определенном выше отношении SP присутствует еще и имя поставщика Sname. Будем для удобства считать, что имя однозначно определяет… · Sn, Pn; · Sname, Pn.

Четвертая нормальная форма

Рассмотрим таблицу R (Subj, Teach, Book), где Subj – учебный предмет, Teach- преподаватель по этому предмету, Book – книга, рекомендуемая… Таблица 1 Записи таблицы R Subj Teach Book Математика Иванов Учебник …

Семантическое моделирование данных.

Семантическое моделирование данных на основе ER-диаграмм компактно и доступно изложено в [5], и мы будем следовать этому источнику. Моделирование… 1. Первоначальное размещение всех атрибутов в одном отношении является очень… 2. Невозможно сразу определить полный список атрибутов. Пользователи имеют привычку называть разными именами одни и те…

Рис. 5

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

Связь типа один ко многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на рис. 4.

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

Каждая связь может иметь одну из двух модальностей связи:

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

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

Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз: <Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 слева направо читается так: "каждый сотрудник может иметь несколько детей", а справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

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

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

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

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

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

· хранить информацию о покупателях;

· печатать накладные на отпущенные товары;

· следить за наличием товаров на складе.

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

· Покупатель- явный кандидат на сущность.

· Накладная- явный кандидат на сущность.

· Товар - явный кандидат на сущность

· Склад(?) - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

· Наличие товара(?) – это, скорее всего, атрибут, но атрибут какой сущности?

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

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

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

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

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

· Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.

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

· Каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

· Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.

· Наименование покупателя - явная характеристика покупателя.

· Адрес - явная характеристика покупателя.

· Банковские реквизиты - явная характеристика покупателя.

· Наименование товара - явная характеристика товара.

· Цена товара(?) - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

· Единица измерения - явная характеристика товара.

· Номер накладной - явная уникальная характеристика накладной.

· Дата накладной - явная характеристика накладной.

· Список товаров в накладной(?) - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.

· Количество товара в накладной(?) - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".

· Цена товара в накладной(?) - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

· Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.

· Наименование склада - явная характеристика склада.

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

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

· каждая накладная обязана иметь несколько записей из списка товаров в накладной;

· каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную;

· каждый товар может включаться в несколько записей из списка товаров в накладной;

· каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром.

Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

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

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

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

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

Сделаем основные выводы.

1. Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование.

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

3. Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных.

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

5. При правильном определении сущностей, полученные таблицы будут сразу находиться в третьей НФ.

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

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

 

Представление деревьев и графов

В реляционной СУБД

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

Основы реляционной алгебры

Реляционная алгебра представляет собой совокупность операций над отношениями. Операндами и результатами операций являются отношения. Рассмотрим… 1. C = A U B- объединение (UNION). Результат образуют кортежи, входящие в A… 2. C = A - B- разность (MINUS). Результат образуют кортежи, входящие как в A, но не входящие в B. Операция корректна…

Основы реляционного исчисления

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

Общая характеристика и стандарты языка SQL

Язык SQL (Structered Query Language) впервые появился в рамках проекта разработки экспериментальной реляционной СУБД System R в исследовательской… После успешного завершения работ по созданию этой системы и получения… Основными функциями SQL являются:

Оператор SELECT языка SQL. Запросы на чтение из одной таблицы. NULL-значения

 

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

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

Рассмотрим сначала простейший вид оператора SELECT для выборки данных из одной таблицы

SELECT [DISTINCT] <список полей> FROM <таблица> WHERE <условие>

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

Например, оператор

SELECT Name, Adress, Rost-Ves AS Ind FROM S WHERE SCity = ‘Москва’ обеспечивает чтение содержимого полей Name, Adress и Ind (вычисляемого поля, определяемого выражением Rost-Ves) из таблицы S для всех записей, у которых значением поля SCity является ‘Москва’.

Символ ‘*’ в списке полей обозначает полный перечень полей таблицы.

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

· сравнение значений с помощью операций ‘=’, ‘<>’, ‘<’, ‘>’, ‘<=’, ‘>=’;

· диапазон значений (BETWEEN);

· членство в множестве ([NOT] IN);

· соответствие шаблону ([NOT] LIKE);

· сравнение с неизвестным значением (IS [NOT] NULL).

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

Условие с BETWEEN можно реализовать и обычными операциями сравнения. Например, запрос

SELECT Name, Adress FROM S WHERE Age BETWEEN Age1 AND Age2

эквивалентен запросу

SELECT Name, Adress FROM S WHERE (Age >= Age1) AND (Age <= Age2)

Членство в множестве задается путем перечисления элементов множества, например

SELECT Name, Adress FROM S WHERE SCity NOT IN (‘Москва’, ‘Петербург’)

Соответствие шаблону требуется обычно для строковых данных. Знак ‘%’ предполагает задание любой последовательности символов, в том числе пустой строки, а знак ‘_’ – одного произвольного символа. Подобное назначение при поиске файлов по маске имеют привычные символы ‘*’ и ’?’.

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

Использование NULL-значений приводит к трехзначной логике, в которой логические выражения могут принимать значения TRUE, FALSE и NULL или UNKNOWN (неизвестно). Значения NULL естественным образом дополняют обычные правила. Например, выражение (Age >= Age1) AND (Age <= Age2) заведомо ложно в том случае, когда Age2 имеет значение NULL, а (Age ≥ Age1) принимает значение FALSE.

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

Таблица 5

Таблица истинности операции NOT

A NOT A
TRUE FALSE
FALSE TRUE
NULL NULL

 

Таблица 6

Таблица истинности операции AND

A B A AND B
TRUE TRUE TRUE
TRUE FALSE FALSE
TRUE NULL NULL
FALSE TRUE FALSE
FALSE FALSE FALSE
FALSE NULL FALSE
NULL TRUE NULL
NULL FALSE FALSE
NULL NULL NULL

 

Таблица 7

Таблица истинности операции OR

A B A OR B
TRUE TRUE TRUE
TRUE FALSE TRUE
TRUE NULL TRUE
FALSE TRUE TRUE
FALSE FALSE FALSE
FALSE NULL NULL
NULL TRUE TRUE
NULL FALSE NULL
NULL NULL NULL

 

Например, запрос

SELECT * FROM Anketa WHERE Adress IS NULL

выдает все записи таблицы Anketa с неизвестным значением поля Adress.

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

ORDER BY Field1 [DESC], Field2 [DESC], …

Сортировка производится в первую очередь по значениям поля Field1, записи с одинаковыми значениями этого поля сортируются по Field2 и т. д. Необязательный параметр DESC вызывает сортировку по убыванию значений.

Можно объединить результаты двух запросов SELECT, вставив между ними c слово UNION. Необходимым условием в этом случае является одинаковое количество выбираемых атрибутов и соответствие их типов в обоих операторах SELECT. Опция ORDER BY при объединении может применяться только к конечному результату.

 

Многотабличные запросы SQL. Соединения таблиц. Самосоединения. Псевдонимы

Запросы могут выбирать данные изнескольких таблиц. Эти таблицы должны быть перечислены после слова FROM. Если таблицы не связаны между собой, то… Снова рассмотрим отношения по поставщикам S (S# , Sn, Scity), изделиям P (P#,… Пусть требуется получить список поставок поставщиков из Москвы с указанием имени поставщика. Запрос

Внешнее соединение таблиц

Рассмотренные соединения называют внутренними (INNER JOIN). В некоторых случаях требуются соединения другого вида – внешние соединения (OUTER JOIN).… Пусть, например, таблицы заполнены следующим образом Таблица 8

Итоговые запросы. Запросы с группировкой

 

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

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

· MIN (поле) – минимальное значение поля; · AVG (поле) – среднее значение поля; · SUM (поле) – сумма значений поля;

Вложенные запросы на чтение

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

Изменение баз данных

Для изменения содержимого таблиц БД применяются три оператора SQL

· INSERT – добавление новых строк;

· DELETE – удаление строк;

· UPDATE – корректировка или обновление строк.

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

· однострочный оператор INSERT позволяет добавить одну новую строку;

· многострочный оператор INSERT обеспечивает извлечение строк из одной части базы данных и добавление их в другую таблицу;

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

Однострочный оператор INSERT имеет формат

INSERT INTO <таблица> [(<список полей>)] VALUES (<список выражений>)

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

INSERT INTO Anketa (Name, Age, Adress)

VALUES (‘ Иванов’, 20, ‘Пушкина, 41-20’)

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

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

INSERT INTO Anketa (Name, Age, Adress)

SELECT Fio, Vozrast, Adr FROM Cartoteka WHERE Vozrast < 60

В результате в таблицу Anketa будет добавлено множество строк из таблицы Cartoteka.

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

Оператор DELETE в простейшем случае имеет вид

DELETE FROM <таблица> WHERE <условие>

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

DELETE FROM Anketa WHERE Age < 18 OR Age IS NULL

Если условие отсутствует, то удаляются все записи. Таблица становится пустой, но из БД не удаляется.

В более сложном варианте оператор DELETE содержит вложенный подзапрос SELECT. Пусть, например, имеются две таблицы с данными об успеваемости студентов A (Nom, Name, Adress) и B (Nom, Subj, Mark). Для удаления всех оценок студента Иванова (точнее, всех студентов с фамилией Иванов) можно использовать оператор

DELETE FROM B WHERE

Nom IN (SELECT Nom FROM A WHERE Name = ‘Иванов’)

Вложенный запрос может иметь несколько уровней.

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

DELETE FROM A, B WHERE A.Nom = B.Nom AND A.Name = ‘Иванов’

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

DELETE FROM A WHERE Name = ‘Иванов’

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

UPDATE A

SET Height = Height * 0.3, Weight = Weight * 0.4

WHERE Country = ‘England’

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

Оператор UPDATE с вложенным подзапросом содержит оператор SELECT в предложении WHERE. Возвращаясь к примеру БД по поставщикам и поставкам, предположим, что принято решение переселить в Москву тех поставщиков, которые имеют более 100 поставок. Это изменение в таблице S можно выполнить оператором

UPDATE A

SET Scity = ‘Москва’

WHERE S# IN

(SELECT S# FROM SP GROUP BY S# HAVING COUNT(*) > 100)

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

 

Целостность данных

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

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

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

Обработка транзакций

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

Операторы создания баз данных

 

В стандарте SQL не указывается способ создания БД, поэтому в различных СУБД это делается по-разному. Например, в СУБД Oracle единая общесистемная БД создается в процессе установки программного обеспечения, в СУБД Ingres входит утилита создания БД, а в СУБД SQL Server используется оператор SQL CREATE DATABASE.

Следующим шагом вслед за созданием пустой БД является заполнение ее таблицами. Оператор CREATE TABLE определяет новую таблицу и подготавливает ее к приему данных. Рассмотрим основные параметры этого оператора на примере

CREATE TABLE Ank

(Idname INTEGER NOT NULL,

Name CHAR (30) NOT NULL,

Numpasp INTEGER NOT NULL UNIQUE,

Iddolgn INTEGER NOT NULL,

Age INTEGER CHECK (Age > 0),

Adress CHAR (50) NOT NULL,

NumOtdel INTEGER NOT NULL,

PRIMARY KEY (Idname),

FOREIGN KEY Otd (Numotdel)

REFERENSES Otdel

ON DELETE CASCADE,

FOREIGN KEY Dol (Iddolgn)

REFERENSES Dolgn

ON UPDATE RESTRICT

ON DELETE RESTRICT)

Этим оператором создается таблица Ank (Idname, Name, Numpasp, Iddolgn, Age, Adress, Numotd). Для каждого поля указываются его тип, размерность, допустимость NULL-значений, уникальность значений поля. Для поля Age определено условие проверки (Age > 0). В качестве первичного ключа (PRIMARY KEY) задано поле Idname. Поля Numotdel и Iddolgn определены как внешние ключи (FOREIGN KEY), связывающие таблицу Ank с таблицами Otdel и Dolgn, а Otd и Dol являются именами связей. При удалении первичного ключа в таблице Otdel каскадно удаляются связанные с ним строки-потомки таблицы Ank, а изменение или удаление первичного ключа в таблице Dolgn запрещено, если есть строки-потомки.

Удаление таблицы выполняется оператором DROP TABLE. Стандарт SQL92 требует, чтобы оператор DROP TABLE включал либо параметр CASCADE, либо RESTRICT , которые оределяют, как влияет удаление таблицы на другие объекты БД, связанные с ней.

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

Одним из средств, обеспечивающим быстрый доступ к строкам таблицы на основе значений одного или нескольких столбцов, является индекс. Индекс создается оператором CREATE INDEX, а удаляется оператором DROP INDEX. В индексе хранятся значения данных и указатели на строки, где эти данные встречаются. Индекс в большой степени ускоряет выполнение операторов SQL с условиями поиска, имеющими ссылки на индексные столбцы. К недостаткам индексов помимо дополнительных затрат внешней памяти относят увеличение трудоемкости выполнения операторов INSERT, DELETE и UPDATE, что связано с необходимостью перестройкой индекса. СУБД всегда создает индекс для первичного ключа.

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

Помимо таблиц и индексов в БД с помощью ключевых слов CREATE, ALTER, DROP создаются, изменяются и удаляются представления (VIEW), триггеры, хранимые процедуры, условия целостности. Эти возможности во многом зависят от конкретных СУБД и соответствующих диалектов SQL.

 

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

Представлением (VIEW) называется SQL-запрос на чтение, которому присвоили имя и сохранили в БД. Представление является виртуальной таблицей, то есть… Представление создается оператором CREATE VIEW. Например, оператор CREATE VIEW SPN AS

Обеспечение безопасности баз данных в SQL

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

Курсоры

Когда результатом выполнения запроса SQL в программном режиме является не одна строка, а целая таблица, необходимо обеспечить для прикладной… 1. Оператор DECLARE CURSOR определяет выполняемый запрос с помощью оператора… 2. Оператор OPEN инициирует выполнение запроса.

Динамический SQL

Концепция, лежащая в основе динамического SQL, проста: встроенный оператор SQL не записывается в исходный текст программы, а формируется в процессе… Наиболее простой формой динамического SQL является оператор EXECUTE IMMEDIATE… Если в программе должны выполняться однотипные операторы SQL, можно по команде PREPARE единственный раз произвести…

Элементы языка QBE

Язык QBE (Query By Example – запрос по образцу) был разработан в компании IBM в 1975 году. Это язык реляционного исчисления с переменными на… Опишем возможности языка QBE на примерах, рассматривая отношения по… 1. Получить имена и номера поставщиков из Москвы.

Подходы к оптимизации запросов

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

Общая стратегия оптимизации определяется на втором и третьем этапах. Рассмотрим их подробнее.

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

Литература

 

1. Мартин Д. Организация баз данных в вычислительных системах. - М.: Мир, 1980.

2. Дейт К. Дж. Введение в системы баз данных, 7-е издание. – М.: Издат. дом “Вильямс”, 2002. – 1072 с.

3. Codd E.F. Is Your DBMS Really Relational and Does Your DBMS Run by the Rules? - Computerword, Octouber, 1985. - № 14, № 21.

4. Мейер Д. Теория реляционных баз данных. - М.: Мир, 1987. – 608 с.

5. Пушников А.Ю. Введение в системы управления базами данных: Учебное пособие в двух частях. – Уфа: Издательство Башкирского университета, 1999. -246 с.

6. Джеймс Р. Грофф, Пол Н. Вайнберг. SQL: полное руководство. - К.: Издательская группа BHV, 2000. - 608 с.

7. Форта Б. Освой самостоятельно SQL. 10 минут на урок. – М.: Издат. дом “Вильямс”, 2006. – 288 с.

8. Ульман Дж. Основы систем баз данных. – М.: Финансы и статистикаб 1983 – 334 с.


Содержание

Введение
1. История создания баз данных
2. Модели данных СУБД
3. Основные понятия реляционной модели данных
4. Двенадцать правил Кодда для реляционных СУБД
5. Нормализация таблиц базы данных. Первая, ворая и третья нормальные формы
6. Нормальная форма Бойса-Кодда
7. Четвертая нормальная форма
8. Семантическая модель данных. Элементы модели “сущность-связь”
9. Представление деревьев и графов в реляционной СУБД
10. Основы реляционной алгебры
11. Основы реляционного исчисления
12. Общая характеристика и стандарты языка SQL
13. Оператор SELECT языка SQL. Запросы на чтение из одной таблицы. NULL-значения
14. Многотабличные запросы SQL. Соединение таблиц. Самосоединения. Псевдонимы
15. Внешнее соединение таблиц
16. Итоговые запросы. Запросы с группировкой
17. Вложенные запросы на чтение
18. Изменение баз данных
19. Целостность данных
20. Триггеры и хранимые процедуры
21. Обработка транзакций
22. Операторы создания БД
23. Представления и работа с ними
24. Обеспечение безопасности баз данных в SQL
25. Курсоры
26. Динамический SQL
27. Элементы языка QBE
28. Подходы к оптимизации запросов
Литература

 

– Конец работы –

Используемые теги: среда, Delphi, широко, известна, вызывает, дополнительных, трудностей, изучении, использовании0.116

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

Что будем делать с полученным материалом:

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

Еще рефераты, курсовые, дипломные работы на эту тему:

Использование среды программирования ТУРБО ПАСКАЛЬ
Основные этапы решения задач на компьютере... Трансляторы... Язык программирования Паскаль...

Методические указания по изучению методов математического программирования Общие рекомендации по использованию программного обеспечения
СОДЕРЖАНИЕ... Общие рекомендации по использованию программного обеспечения... Элементарные преобразования матриц Метод Гаусса...

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

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

Проблемы, связанные с известными методическими трудностями преподавания студентам-социологам дисциплин, содержащих математический компонент
На сайте allrefs.net читайте: "Проблемы, связанные с известными методическими трудностями преподавания студентам-социологам дисциплин, содержащих математический компонент"

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

Разработка Интерфейса Пользователя АСУ в Среде Delphi
Вместе с тем при анализе неудовлетворенности пользователей АСУ удается выявить, что она часто объясняется отсутствием единого, комплексного подхода… Значение системного подхода особенно велико при проектировании и эксплуатации… Системный подход при проектировании представляет собой комплексное, взаимосвязанное, пропорциональное рассмотрение…

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

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

Изучение среды разработки Microsoft Visual Studio
Национальный аэрокосмический университет им Н Е Жуковского Харьковский авиационный институт...

0.048
Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • По категориям
  • По работам