Базы данных

Преобразование ER-модели в реляционную модель. Создание бинарных связей в программе ERModeler. Использование системы управления базами данных SQL Server версии 2005 в качестве среды программирования. Использование условий отбора и агрегирующих функций.

Рубрика Программирование, компьютеры и кибернетика
Вид учебное пособие
Язык русский
Дата добавления 20.08.2014
Размер файла 551,0 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

О.В. Пинягина, И.А. Фукин

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

46

КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ

Практикум по курсу

“Базы данных”

ПИНЯГИНА О.В., ФУКИН И.А.

Казань 2012

Содержание

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

ER-модель (ENTITY-RELATIONSHIP MODEL)

Пример ER-модели: контора «Рога и копыта»

Пример ER-модели: «Музыканты»

Задание для индивидуальной работы 1

Преобразование ER-модели в реляционную модель

Пример реляционной модели: контора «Рога и копыта»

Пример реляционной модели «Музыканты»

Задание для индивидуальной работы 2

SQL (STRUCTURED QUERY LANGUAGE)

SQL SERVER - коротко о главном

DDL. Таблицы

Пример сценария создания БД «Рога и копыта»

Задание для индивидуальной работы 3

DML. Изменение данных

Задание для индивидуальной работы 4

DQL. Запросы

Выборка из одной таблицы

Использование условий отбора

Использование агрегирующих функций

Сортировка

Подзапросы

Группировка

Выборка из нескольких таблиц

Объединение запросов

И еще несколько примеров

Задание для индивидуальной работы 5

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

Задание для индивидуальной работы 6

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

Задание для индивидуальной работы 7

CCL. Курсоры

Задание для индивидуальной работы 8

Триггеры

Задание для индивидуальной работы 9

Приложение 1. Работа с ERMODELER

Приложение 2. Некоторые типичные ошибки SQL

Приложение 3. Реляционная алгебра и SQL

Литература

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

реляционный бинарный программирование агрегирующий

ER-модель (entity-relationship model)

Работа с базой данных начинается с построения модели предметной области. Наиболее распространенной является ER-модель (entity-relationship model) - модель «Сущность-связь».

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

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

Базовые понятия:

Сущность (объект)

Атрибут сущности (свойство, характеризующее объект)

Ключевой атрибут (атрибут, входящий в первичный ключ)

Связь

Работает

Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующих объект.

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

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

Связи между объектами могут быть 3-х типов:

Один - к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот.

Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель.

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

Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в одном отделе.

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

Например: каждый счет может включать множество товаров, и каждый товар может входить в разные счета.

Связь может соединять сущность саму с собой, например:

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

Пусть, например, номер сотрудника является уникальным только в пределах отдела, т.е. в разных отделах могут быть сотрудники с одинаковыми номерами. Уникальной в данном случае будет комбинация атрибутов «НомерСотрудника, НомерОтдела». Сущность «Сотрудник» является слабой.

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

Слабая сущность

Связь слабой сущности

Иногда для более удобной классификации используются так называемые подтипы сущностей. Их обозначают с помощью треугольника, направленного от подтипа к надтипу. Этот треугольник может сопровождаться надписью «есть» или «is a» (т.е., «является»).

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

Сущность «Контрагент» является надтипом для своих подтипов. Обратите внимание, что у подтипов обычно не бывает собственных первичных ключей.

Замечания по поводу связи М:М

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

Если связь соединяет две сущности, она называется бинарной.

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

Связь с арностью более 2 обычно имеет тип многие - ко многим по отношению ко всем связанным сущностям.

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

Пример ER-модели: Контора «Рога и копыта»

Описание задачи

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

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

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

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

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

Пример ER-модели: «Музыканты»

Описание задачи [3]

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

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

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

Музыкант может играть на разных инструментах с разной степенью квалификации.

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

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

Задание для индивидуальной работы 1

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

Преобразование ER-модели в реляционную модель

Дано: ER-модель.

Получить: набор таблиц (отношений) следующего вида

Таблица (Ключ, Атрибут1, Атрибут2, …, АтрибутN)

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

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

Внешним ключом (foreign key) называют ссылку на родительский объект. Обычно внешние ключи появляются в таблицах в результате преобразования связей. Будем выделять внешние ключи курсивом.

Для краткости в некоторых примерах пропущены несущественные неключевые атрибуты.

I. Преобразование сущностей

1. Преобразование обычной сущности

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

Сущность (Ключ, Атрибут1, Атрибут2)

2. Преобразование слабой сущности

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

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

Для слабой сущности они будут являться внешними ключами.

Сущность1 (Ключ1, Ключ2, Атрибут1, Атрибут2)

3. Преобразование подтипов сущностей.

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

Сущность1 (Ключ, Атрибут1, Атрибут2, Атрибут3, Атрибут4, Атрибут4, Признак)

Недостатком этого способа является то, что в таблице остается много незаполненных полей: для объекта подтипа 1 атрибуты 4 и 5, а для объекта подтипа 2 - атрибуты 2 и 3 останутся пустыми.

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

Подтип1 (Ключ, Атрибут1, Атрибут2, Атрибут3)

Подтип2 (Ключ, Атрибут1, Атрибут4, Атрибут5)

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

3 способ. Создается одна таблица для надтипа и по одной таблице для каждого подтипа, в которую включаются ключевые поля надтипа:

Сущность1 (Ключ, Атрибут1)

Подтип1 (Ключ, Атрибут2, Атрибут3)

Подтип2 (Ключ, Атрибут4, Атрибут5)

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

II. Преобразование связей

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

1. Связь М:М

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

Сущность1 (Ключ1, Атрибут1, Атрибут2)

Сущность2 (Ключ2, Атрибут3, Атрибут4)

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

Сущ1Сущ2 (Ключ1, Ключ2, Атрибут5)

2. Связь 1:М

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

Сущность1 (Ключ1, Атрибут1, Атрибут2)

Сущность2 (Ключ2, Атрибут3, Атрибут4)

Сущ1Сущ2 (Ключ1, Ключ2)

Этот способ предпочтительнее использовать в том случае, если связь не является «ровно к одному», то есть не все экземпляры сущностей участвуют в связи.

2 способ. Новая таблица для связи не создается, а в таблицу дочерней сущности добавляют ключевые поля родительской сущности (в первичный ключ дочерней сущности они входить не будут!). Ключевые поля родительской сущности представляют собой внешний ключ для дочерней сущности.

Сущность1 (Ключ1, Атрибут1, Атрибут2)

Сущность2 (Ключ2, Атрибут3, Атрибут4, Ключ1)

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

3. Связь 1:1

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

Первичным ключом этой таблицы будет ключ любой сущности.

Сущность1 (Ключ1, Атрибут1, Атрибут2)

Сущность2 (Ключ2, Атрибут3, Атрибут4)

Сущ1Сущ2 (Ключ1, Ключ2) или Сущ1Сущ2 (Ключ1, Ключ2)

Этот способ предпочтительнее использовать в том случае, если связь не является связью «ровно к одному», то есть не все экземпляры сущностей участвуют в связи.

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

Сущность1 (Ключ1, Атрибут1, Атрибут2)

Сущность2 (Ключ2, Атрибут3, Атрибут4, Ключ1)

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

3 способ. Две таблицы для сущностей, связанных соотношением 1:1, объединяются в одну. Ключом новой таблицы может быть комбинация ключей обеих таблиц. Если хотя бы в одном направлении связь «ровно к одному», то ключ этой сущности можно считать ключом объединенной таблицы.

Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2)

или, возможно, Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2),

или Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2).

Примечание 1:

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

Рассмотрим связь 1:M, способ 2. Переименован внешний ключ.

Сущность1 (Ключ1, Атрибут1, Атрибут2, ЕщеОдинКлюч1).

Примечание 2

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

Сущ1Сущ2Сущ3 (Ключ1, Ключ2, Ключ3)

Пример реляционной модели: Контора «Рога и копыта»

Таблицы удобнее называть существительными во множественном числе.

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

Отделы (Ном_отд, Полное_назв_отд, Краткое_назв_отд, Ном_сотр)

Поле Ном_сотр содержит номер сотрудника-руководителя отдела и является результатом преобразования связи 1:1 «Имеет руководителя».

Сотрудники (Ном_сотр, ФИО, Должность, Дата_приема, Срок, Ном_отд)

Ном_отд появился в результате преобразования связи 1:М «Состоит из», в первичный ключ он не входит.

Предприятия (Ном_пред, Наз_пред, Адрес, Телефон)

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

Договоры (Ном_дог, Дата_дог, Тип_дог, Ном_сотр, Ном_пред)

Ном_сотр появился в результате преобразования связи М:1 «Выписан», в первичный ключ он не входит, Ном_пред появился в результате преобразования связи 1:М «Заключает», в первичный ключ он не входит.

Счета (Ном_сч, Дата_сч, Срок_сч, Сумма_сч, Ном_дог, Пени)

Ном_дог появился в результате преобразования связи 1:М «Включает», в первичный ключ он не входит.

Платежи (Ном_пл, Ном_сч, Дата_пл, Сумма_пл)

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

Товары/услуги (Ном_ту, Назв_ту, Цена_ту)

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

Протоколы_счетов (Ном_сч, Ном_ту, Количество, Цена)

Эта таблица появилась в результате преобразования бинарной связи М:М «Состав счета», её первичный ключ состоит из ключевых полей обеих сущностей.

Пример реляционной модели: «Музыканты»

Музыканты (НомМуз, ИмяМуз, ДатаРожд, СтрРожд)

Эта таблица не имеет внешних ключей.

Сочинения (НомСоч, НазСоч, ДатаСоч, НомМуз)

Столбец НомМуз является внешним ключом, появился в результате преобразования связи 1:М «Композитор» и содержит номера музыкантов- композиторов.

Исполнители (НомИсп, Инструмент, Оценка, НомМуз)

Столбец НомМуз является внешним ключом, появился в результате преобразования связи 1:М «Является» с сущностью «Музыканты».

Ансамбли (НомАнс, НазАнс, СтрАнс, НомМуз)

Столбец НомМуз является внешним ключом, появился в результате преобразования связи 1:М «Руководитель».

УчАнс(НомАнс, НомИсп)

Эта таблица появилась в результате преобразования бинарной связи М:М «Участники», её первичный ключ состоит из ключевых полей обеих связанных сущностей.

Исполнения (НомМуз, НомАнс, НомСоч, ДатаИсп, СтрИсп, ГорИсп)

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

Задание для индивидуальной работы 2

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

SQL (Structured Query Language)

SQL Server - коротко о главном

В качестве среды программирования мы будем использовать СУБД (систему управления базами данных) SQL Server версии 2005 или выше, Express Edition.

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

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

· многоплатформность;

· поддержка 64-разрядной архитектуры;

· масштабируемость (многопроцессорная обработка и поддержка терабайтных БД - 10е12 байт);

· стандарт SQL92 (язык Transact SQL);

· параллельные архивирование и восстановление БД;

· репликация данных;

· распределенные запросы;

· распределенные транзакции;

· динамические блокировки;

· интеграция с IIS и Visual Studio.

Существуют дистрибутивы для разных версий операционной системы Windows, как 32-битовых, так и 64-битовых.

Установка

1 этап. Установите SQL Server Express из дистрибутива. Учтите, что для установки требуется.Net Framework 2.0 (для 2005) или более поздняя версия. Не забудьте включить текущего пользователя в группу администраторов. Для версии 2008 установка выглядит несколько сложнее; если возникают трудности, пользуйтесь справочной системой сайта Microsoft.com.

В процессе установки в общем меню программ создается папка Microsoft SQL Server. В этой папке в подпапке Configuration Tools содержится очень полезная утилита с названием SQL Server Configuration Manager. С помощью этой утилиты можно запускать и останавливать сервер, а также выполнять его настройку.

2 этап. Установите SQL Server Management Studio. Эта среда позволяет как выполнять некоторые административные задачи с помощью визуальных средств, так и запускать SQL-сценарии в текстовом режиме.

Запустите SQL Server Management Studio. При запуске задается имя сервера (обычно оно выглядит как ИмяКомпьютера\SQLEXPRESS).

Служебные базы данных, которые создаются по умолчанию:

· master - системная БД с конфигурацией SQLServer;

· model - шаблон для всех пользовательских БД;

· msdb - планирование заданий по расписанию и т.п.;

· tempdb - БД для временных объектов.

Любая БД состоит из:

· диаграмм (автоматически не создаются!);

· таблиц (пользовательских и системных);

· представлений;

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

· пользователей;

· ролей;

· правил;

· значений по умолчанию;

· пользовательских типов.

БД можно создать:

· с помощью визуальных средств Management Studio: (Databases - New database);

· с помощью средств ER-проектирования, например Platinum ERWin,

· с помощью SQL-команд, запуская их из SQL Management Studio.

Главный файл БД (один) имеет тип.MDF. Можно задавать дополнительные файлы, их тип .NDF. Файл журнала транзакций имеет тип.LDF.

SQL Server Management Studio позволяет выполнять как отдельные SQL-команды, так и SQL-файлы целиком.

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

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

SQL Server Express edition не включает в себя справочную систему. Вся необходимая информация может быть найдена в онлайн-режиме в справочной системе Microsoft MSDN на сайте msdn.microsoft.com.

DDL. Таблицы

DDL (Data Definition Language) - язык описания данных, составная часть SQL. Рассмотрим команды создания базы данных и таблиц.

Для создания базы данных служит команда

CREATE DATABASE имя_БД

Для активизации базы данных служит команда

USE имя_БД

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

Для создания таблиц используется команда CREATE TABLE.

Краткий формат этой команды (квадратные скобки означают необязательные элементы):

CREATE TABLE имя_таблицы(

Список_определений_полей,

[Список_ограничений_таблицы]);

Более подробно смотрите в MSDN.

Определение поля имеет формат:

Имя_поля тип_поля[(размер)]

[NULL] [NOT NULL]

[IDENTITY]

[DEFAULT умолчание]

[Список_ограничений_поля]

Ограничение поля имеет формат

[CHECK (условие)]

[PRIMARY KEY]

[UNIQUE]

[REFERENCES имя_таблицы(имя_поля)]

Чаще всего используются типы полей:

VARCHAR - строковый тип переменной длины;

NUMERIC - числовой тип;

DATETIME - тип дата/время.

Какие еще типы полей есть в SQL server? - обращайтесь к MSDN.

NULL - специальное «неопределенное» значение, предусмотренное стандартом SQL. Определение NULL/NOT NULL служит для указания, что данный тип поля допускает/запрещает ввод NULL-значений.

IDENTITY начальное_значение, приращение - определение, указывающее, что данное поле представляет собой счетчик. Это означает, что значения в данное поле вставляются сервером с нарастанием автоматически при вставке строки. Если «начальное_значение» и «приращение» пропущены, они полагаются равными 1.

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

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

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

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

Например, в таблице «Предприятия» номер предприятия будет первичным ключом и счетчиком, название фирмы не допускает значений NULL:

CREATE TABLE k_firm

(firm_num NUMERIC(6) IDENTITY PRIMARY KEY,

firm_name VARCHAR(100) NOT NULL,

firm_addr VARCHAR(100)

);

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

CREATE TABLE k_contract

contract_num NUMERIC(6) IDENTITY PRIMARY KEY,

contract_date DATETIME DEFAULT GETDATE(),

contract_type CHAR(1)

CHECK (contract_type IN ('A','B','C')),

firm_num NUMERIC(6) NOT NULL,

staff_num NUMERIC(6)

);

REFERENCES имя_таблицы(имя_поля) - ограничение внешнего ключа, или декларативной ссылочной целостности.

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

CREATE TABLE k_staff

(staff_num NUMERIC(6) IDENTITY,

staff_name VARCHAR(30) NOT NULL,

staff_post VARCHAR(30),

dept_num NUMERIC(6)

REFERENCES k_dept (dept_num),

staff_hiredate DATETIME NOT NULL,

staff_termdate DATETIME

);

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

Ограничение CHECK уровня таблицы может быть определено, например, так:

CREATE TABLE k_bill

(bill_num NUMERIC(6) IDENTITY PRIMARY KEY,

bill_date DATETIME DEFAULT GETDATE(),

bill_term DATETIME DEFAULT GETDATE()+30,

contract_num NUMERIC(6),

CONSTRAINT ch_bill_date CHECK (bill_term-bill_date<91)

);

т.е., срок действия счета не может превышать 91 день.

Ограничение внешнего ключа на уровне таблицы определяется так:

CONSTRAINT имя_ограничения FOREIGN KEY (список_полей)

REFERENCES родительская_таблица(внешний ключ)

например,

CREATE TABLE k_contract

(contract_num NUMERIC(6) IDENTITY PRIMARY KEY,

contract_date DATETIME DEFAULT GETDATE(),

contract_type CHAR(1)

CHECK (contract_type IN ('A','B','C')),

firm_num NUMERIC(6) NOT NULL,

staff_num NUMERIC(6),

CONSTRAINT fk_contract_firm_num FOREIGN KEY (firm_num)

REFERENCES k_firm (firm_num),

CONSTRAINT fk_contract_staff_num FOREIGN KEY (staff_num)

REFERENCES k_staff (staff_num)

);

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

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

CONSTRAINT имя_ограничения PRIMARY KEY (список_полей)

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

CREATE TABLE k_protokol

price_num NUMERIC(6) NOT NULL,

bill_num NUMERIC(6) NOT NULL,

kolvo NUMERIC(6) NOT NULL,

price_sum NUMERIC(9,2) NOT NULL,

CONSTRAINT pk_protokol_num

PRIMARY KEY (price_num, bill_num),

CONSTRAINT fk_protokol_price_num FOREIGN KEY (price_num)

REFERENCES k_price (price_num),

CONSTRAINT fk_protokol_bill_num FOREIGN KEY (bill_num)

REFERENCES k_bill (bill_num)

);

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

Пример сценария создания БД "Рога и копыта"

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

CREATE DATABASE kontora

USE kontora

Таблица "Предприятия"

CREATE TABLE k_firm

(firm_num NUMERIC(6) IDENTITY PRIMARY KEY,

firm_name VARCHAR(100) NOT NULL,

firm_addr VARCHAR(100),

firm_phone NUMERIC(7)

)

Таблица "Отделы"

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

CREATE TABLE k_dept

(dept_num NUMERIC(6) IDENTITY PRIMARY KEY,

dept_short_name VARCHAR(10) NOT NULL,

dept_full_name VARCHAR(100),

staff_num NUMERIC(6)

)

Таблица "Сотрудники"

После создания этой таблицы сразу же можем определить внешний ключ для поля staff_num таблицы k_dept. Это можно сделать с помощью команды ALTER TABLE.

CREATE TABLE k_staff

(staff_num NUMERIC(6) IDENTITY,

staff_name VARCHAR(30) NOT NULL,

staff_post VARCHAR(30),

dept_num NUMERIC(6),

staff_hiredate DATETIME NOT NULL,

staff_termdate DATETIME,

CONSTRAINT pk_staff_num PRIMARY KEY (staff_num),

CONSTRAINT fk_staff_dept_num FOREIGN KEY (dept_num)

REFERENCES k_dept (dept_num)

)

ALTER TABLE k_dept ADD CONSTRAINT fk_staff_num

FOREIGN KEY (staff_num)

REFERENCES k_staff(staff_num)

Таблица "Договоры"

CREATE TABLE k_contract

(contract_num NUMERIC(6) IDENTITY PRIMARY KEY,

contract_date DATETIME DEFAULT GETDATE(),

contract_type CHAR(1)

CHECK (contract_type IN ('A','B','C')),

firm_num NUMERIC(6) NOT NULL,

staff_num NUMERIC(6),

CONSTRAINT fk_contract_firm_num FOREIGN KEY (firm_num)

REFERENCES k_firm (firm_num),

CONSTRAINT fk_contract_staff_num FOREIGN KEY (staff_num)

REFERENCES k_staff (staff_num)

)

Таблица "Счета"

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

CREATE TABLE k_bill

(bill_num NUMERIC(6) IDENTITY PRIMARY KEY,

bill_date DATETIME DEFAULT GETDATE(),

bill_term DATETIME DEFAULT GETDATE()+30,

bill_peni NUMERIC(6) DEFAULT 0,

contract_num NUMERIC(6),

CONSTRAINT fk_bill_contract_num

FOREIGN KEY (contract_num)

REFERENCES k_contract (contract_num),

CONSTRAINT ch_bill_date CHECK (bill_term-bill_date<91)

)

ALTER TABLE k_bill ADD bill_sum NUMERIC(6) DEFAULT 0 NOT NULL

Таблица "Платежи"

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

CREATE TABLE k_payment

(payment_num NUMERIC(2) DEFAULT 0,

bill_num NUMERIC(6),

payment_date DATETIME DEFAULT GETDATE(),

payment_sum NUMERIC(9,2),

CONSTRAINT pk_payment_num

PRIMARY KEY (payment_num, bill_num),

CONSTRAINT fk_payment_bill_num FOREIGN KEY (bill_num)

REFERENCES k_bill (bill_num)

)

Таблица "Товары/услуги" (или "Прайс-лист")

CREATE TABLE k_price

(price_num NUMERIC(6) IDENTITY PRIMARY KEY,

price_name VARCHAR(100) NOT NULL,

price_sum NUMERIC(9,2),

type_num NUMERIC(6)

)

Таблица "Протоколы счетов"

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

CREATE TABLE k_protokol

(price_num NUMERIC(6) NOT NULL,

bill_num NUMERIC(6) NOT NULL,

kolvo NUMERIC(6) NOT NULL,

price_sum NUMERIC(9,2),

CONSTRAINT pk_protokol_num

PRIMARY KEY (price_num, bill_num),

CONSTRAINT fk_protokol_price_num FOREIGN KEY (price_num)

REFERENCES k_price (price_num),

CONSTRAINT fk_protokol_bill_num FOREIGN KEY (bill_num)

REFERENCES k_bill (bill_num)

)

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

Перед удалением каждой таблицы выполняется проверка - существует ли эта таблица. Информацию обо всех объектах БД можно получить из системной таблицы sysobjects. Тип объекта базы данных `U' означает `user table', т.е., пользовательская таблица, `F' - `foreigh key', т.е., внешний ключ. Для нашей базы данных сценарий может выглядеть следующим образом:

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_payment' AND type='U')

DROP TABLE k_payment

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_protokol' AND type='U')

DROP TABLE k_protokol

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_bill' AND type='U')

DROP TABLE k_bill

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_price' AND type='U')

DROP TABLE k_price

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_contract' AND type='U')

DROP TABLE k_contract

IF EXISTS( SELECT name FROM sysobjects

WHERE name='fk_staff_num' AND type='F')

ALTER TABLE k_dept DROP CONSTRAINT fk_staff_num

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_staff' AND type='U')

DROP TABLE k_staff

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_dept' AND type='U')

DROP TABLE k_dept

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_firm' AND type='U')

DROP TABLE k_firm

IF EXISTS( SELECT name FROM sysobjects

WHERE name='k_bill_list' AND type='U')

DROP TABLE k_bill_list

Удаляются сначала дочерние таблицы, затем родительские.

Таблицы "Отделы" и "Сотрудники" взаимно ссылаются друг на друга по внешним ключам, поэтому сначала приходится удалить одно из ограничений внешнего ключа, и только потом удалять таблицы. Можно ли в данном случае поступить наоборот, т.е. удалить ограничение из таблицы k_staff? Что еще нужно будет изменить в сценарии?

Вопрос.

Чем отличаются ограничения уровня поля и ограничения уровня таблицы?

Задание для индивидуальной работы 3

Напишите и отладьте SQL-сценарий создания вашей базы данных и таблиц для нее.

DML. Изменение данных

DML (Data Manipulation Language) - язык манипулирования данными, составная часть SQL.

Рассмотрим его основные команды - команды добавления, изменения и удаления данных INSERT, UPDATE и DELETE.

Для добавления новых строк в таблицу служит команда INSERT:

INSERT [INTO] имя_таблицы [(список_полей)]

VALUES (список_значений);

Например,

INSERT k_firm (firm_name, firm_addr)

VALUES('Альфа', 'Москва');

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

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

SET IDENTITY_INSERT ON

Если мы вставляем значения из одной таблицы в другую, формат команды INSERT следующий:

INSERT [INTO] имя_таблицы [(список_полей)]

(SELECT параметры);

Для обновления данных используется команда UPDATE:

UPDATE имя_таблицы

SET поле1=выражение1 [,…, полеN=ВыражениеN]

[WHERE условие];

Например,

UPDATE k_dept SET staff_num=1

WHERE dept_short_name='Sales';

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

Для удаления данных используется команда DELETE:

DELETE [FROM] имя_таблицы [WHERE условие];

Например,

DELETE FROM k_dept WHERE dept_short_name='Sales';

Если опция WHERE пропущена, удалены будут все строки таблицы.

Заполним тестовыми данными нашу базу «Рога и копыта». Кроме команд добавления, для примера рассмотрены несколько команд изменения данных. Обратите внимание, что для полей, имеющих свойство IDENTITY, значения не задаются - они будут генерироваться автоматически.

Строки-константы следует задавать в одинарных кавычках.

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

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

SET DATEFORMAT dmy

Мы будем использовать формат год:месяц:день

SET DATEFORMAT ymd

при котором константа-дата выглядит так: `2012-01-31'

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

Таблица "Предприятия"

INSERT INTO k_firm (firm_name, firm_addr)

VALUES('Альфа', 'Москва');

INSERT INTO k_firm (firm_name, firm_addr)

VALUES('Бета', 'Казань');

INSERT INTO k_firm (firm_name, firm_addr)

VALUES('Гамма', 'Париж');

INSERT INTO k_firm (firm_name, firm_addr)

VALUES('Дельта', 'Лондон');

INSERT INTO k_firm (firm_name, firm_addr)

VALUES('Омега', 'Токио');

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

SELECT * FROM k_firm;

Результат будет выглядеть следующим образом (поле firm_phone мы не заполняли, поэтому в нем будут значения NULL):

firm_num firm_name firm_addr firm_phone

-------------------------------------------

1 Альфа Москва NULL

2 Бета Казань NULL

3 Гамма Париж NULL

4 Дельта Лондон NULL

5 Омега Токио NULL

(5 row(s) affected)

Таблица "Отделы"

INSERT INTO k_dept (dept_short_name, dept_full_name)

VALUES('Sales', 'Отдел продаж');

INSERT INTO k_dept (dept_short_name, dept_full_name)

VALUES('Mart', 'Отдел маркетинга');

INSERT INTO k_dept (dept_short_name, dept_full_name)

VALUES('Cust', 'Отдел гарантийного обслуживания');

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

SELECT * FROM k_dept;

dept_num dept_short_name dept_full_name staff_num

-----------------------------------------------------

1 Sales Отдел продаж NULL

2 Mart Отдел маркетинга NULL

3 Cust Отдел гарантийного обслуживания NULL

(3 row(s) affected)

Таблица "Сотрудники"

INSERT INTO k_staff

(staff_name, dept_num, staff_hiredate, staff_post)

VALUES('Иванов', 1, '1999-01-01', 'Менеджер');

INSERT INTO k_staff

(staff_name, dept_num, staff_hiredate, staff_post) VALUES('Петров', 2, '2010-10-13','Менеджер');

INSERT INTO k_staff

(staff_name, dept_num, staff_hiredate, staff_post) VALUES('Сидоров', 3, '2005-12-01','Менеджер');

INSERT INTO k_staff

(staff_name, staff_hiredate, staff_post)

VALUES('Семенов', '1990-01-01','Директор');

INSERT INTO k_staff

(staff_name, dept_num, staff_hiredate, staff_post) VALUES('Григорьев', 3, '2008-12-19','Программист');

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

SELECT * FROM k_staff;

staff staff staff dept staff staff

_num _name _post _num _hiredate _termdate

--------------------------------------- -------------------

1 Иванов Менеджер 1 1999-01-01 00:00:00.000 NULL

2 Петров Менеджер 2 2010-10-13 00:00:00.000 NULL

3 Сидоров Менеджер 3 2005-12-01 00:00:00.000 NULL

4 Семенов Директор NULL 1990-01-01 00:00:00.000 NULL

5 Григорьев Программист 3 2008-12-19 00:00:00.000 NULL

(3 row(s) affected)

После того как мы заполнили таблицу "Сотрудники", мы можем в таблице "Отделы" заполнить столбец staff_num, содержащий код руководителя отдела.

UPDATE k_dept SET staff_num=2

WHERE dept_short_name='Mart';

UPDATE k_dept SET staff_num=3

WHERE dept_short_name='Cust';

UPDATE k_dept SET staff_num=1

WHERE dept_short_name='Sales';

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

SELECT * FROM k_dept;

dept_num dept_short_name dept_full_name staff_num

--------------------------------------------------------

1 Sales Отдел продаж 1

2 Mart Отдел маркетинга 2

3 Cust Отдел гарантийного обслуживания 3

(3 row(s) affected)

Таблица "Договоры"

INSERT INTO k_contract

(contract_type, firm_num, staff_num, contract_date)

VALUES('A', 1, 1,'2011-11-01');

INSERT INTO k_contract

(contract_type, firm_num, staff_num, contract_date)

VALUES('B', 1, 2,'2011-10-01');

INSERT INTO k_contract

(contract_type, firm_num, staff_num, contract_date)

VALUES('C', 1, 1,'2011-09-01');

INSERT INTO k_contract

(contract_type, firm_num, staff_num, contract_date)

VALUES('A', 2, 2,'2011-11-15');

INSERT INTO k_contract

(contract_type, firm_num, staff_num, contract_date)

VALUES('B', 2, 2,'2011-08-01');

INSERT INTO k_contract

(contract_type, firm_num, staff_num, contract_date)

VALUES('C', 3, 1,'2011-07-15');

INSERT INTO k_contract

(contract_type, firm_num, staff_num, contract_date)

VALUES('A', 4, 1,'2011-11-12');

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

SELECT * FROM k_contract;

contract_num contract_date contract_type firm_num staff_num

-----------------------------------------------------------

1 2011-11-01 00:00:00.000 A 1 1

2 2011-10-01 00:00:00.000 B 1 2

3 2011-09-01 00:00:00.000 C 1 1

4 2011-11-15 00:00:00.000 A 2 2

5 2011-08-01 00:00:00.000 B 2 2

6 2011-07-15 00:00:00.000 C 3 1

7 2011-11-12 00:00:00.000 A 4 1

(7 row(s) affected)

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

Таблица "Счета"

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(1, '2011-11-12', '2011-12-12', 1000);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(1, '2011-12-12', '2012-01-12', 2000);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(1, '2012-01-12', '2012-02-12',2000);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(2, '2011-12-12', '2012-01-12', 6000);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(2, '2012-01-12', '2012-02-12', 2000);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(3, '2012-01-12', '2012-02-12', 2500);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(4, '2011-12-12', '2012-01-12', 1500);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(5, '2011-12-12', '2012-01-12', 1200);

INSERT INTO k_bill

(contract_num, bill_date, bill_term, bill_sum)

VALUES(5, '2012-01-12', '2012-02-12', 10000);

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

SELECT * FROM k_bill;

bill bill bill bill contract bill

_num _date _term _peni _num _sum

-----------------------------------------------------------

1 2011-11-12 00:00:00.000 2011-12-12 00:00:00.000 0 1 1000

2 2011-12-12 00:00:00.000 2012-01-12 00:00:00.000 0 1 2000

3 2012-01-12 00:00:00.000 2012-02-12 00:00:00.000 0 1 2000

4 2011-12-12 00:00:00.000 2012-01-12 00:00:00.000 0 2 3000

5 2012-01-12 00:00:00.000 2012-02-12 00:00:00.000 0 2 2000

6 2012-01-12 00:00:00.000 2012-02-12 00:00:00.000 0 3 2500

7 2011-12-12 00:00:00.000 2012-01-12 00:00:00.000 0 4 1000

8 2011-12-12 00:00:00.000 2012-01-12 00:00:00.000 0 5 1200

9 2012-01-12 00:00:00.000 2012-02-12 00:00:00.000 0 5 2000

(9 row(s) affected)

Таблица "Платежи"

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(1, 1, '2011-12-01', 1000);

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(1, 2, '2011-12-15', 1000);

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(1, 3, '2012-01-13', 1500);

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(2, 3, '2012-01-15', 500);

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(1, 4, '2012-01-12', 1000);

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(1, 7, '2012-01-05', 100);

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(2, 7, '2012-01-12', 900);

INSERT INTO k_payment

(payment_num, bill_num, payment_date, payment_sum)

VALUES(1, 8, '2011-12-25', 1000);

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

SELECT * FROM k_payment;

payment_num bill_num payment_date payment_sum

-----------------------------------------------------------

1 1 2011-12-01 00:00:00.000 1000.00

1 2 2011-12-15 00:00:00.000 1000.00

1 3 2012-01-13 00:00:00.000 1500.00

1 4 2012-01-12 00:00:00.000 1000.00

1 7 2012-01-05 00:00:00.000 100.00

1 8 2011-12-25 00:00:00.000 1000.00

2 3 2012-01-15 00:00:00.000 500.00

2 7 2012-01-12 00:00:00.000 900.00

(8 row(s) affected)

Таблица "Товары/услуги" (или "Прайс-лист")

INSERT INTO k_price (price_name, price_sum, type_num)

VALUES('Материализация духов',1000, 2);

INSERT INTO k_price (price_name, price_sum, type_num)

VALUES('Раздача слонов',100, 2);

INSERT INTO k_price (price_name, price_sum, type_num)

VALUES('Слоновий бивень',3000, 1);

INSERT INTO k_price (price_name, price_sum, type_num)

VALUES('Моржовый клык',1500, 1);

INSERT INTO k_price (price_name, price_sum, type_num)

VALUES('Копыто Пегаса',5000, 1);

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

SELECT * FROM k_price;

price_num price_name price_sum type_num

-----------------------------------------------------------

1 Материализация духов 1000.00 2

2 Раздача слонов 100.00 2

3 Слоновий бивень 3000.00 1

4 Моржовый клык 1500.00 1

5 Копыто Пегаса 5000.00 1

(5 row(s) affected)

Таблица "Протоколы счетов"

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(1, 1, 1, 1000);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(1, 2, 2, 1000);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(2, 3, 20, 100);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(3, 4, 2, 3000);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(1, 5, 1, 1000);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(2, 5, 10, 100);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(1, 6, 2, 1000);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(2, 6, 5, 100);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(4, 7, 1, 1500);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(1, 8, 1, 1000);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(2, 8, 2, 100);

INSERT INTO k_protokol

(price_num, bill_num, kolvo, price_sum)

VALUES(5, 9, 2, 5000);

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

SELECT * FROM k_ protokol;

price_num bill_num kolvo price_sum

-----------------------------------------------------------

1 1 1 1000.00

1 2 2 1000.00

1 5 1 1000.00

1 6 2 1000.00

1 8 1 1000.00

2 3 20 100.00

2 5 10 100.00

2 6 5 100.00

2 8 2 100.00

3 4 2 3000.00

4 7 1 1500.00

5 9 2 5000.00

(12 row(s) affected)

Вопрос

Можно ли для таблицы, в которой имеется поле IDENTITY, выполнить команду INSERT, не указывая явно список полей? Проверьте.

Задание для индивидуальной работы 4

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

DQL. Запросы

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

...

Подобные документы

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

    реферат [27,5 K], добавлен 10.01.2011

  • Освоение сервисной системы управления базами данных Microsoft SQL. Разработка базы данных "Служба АТС" в среде Microsoft SQL Server Management Studio и создание запросов на языке SQL. Апробация инфологической модели "сущность - связь" базы данных.

    курсовая работа [2,9 M], добавлен 29.06.2015

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

    реферат [123,0 K], добавлен 22.06.2011

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

    лабораторная работа [70,6 K], добавлен 13.02.2013

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

    реферат [115,8 K], добавлен 19.12.2011

  • Проектирование базы данных для автоматизированной системы "Склад". Разработка концептуальной модели (ER-диаграмма). Преобразование в реляционную модель и ее нормализация. Разработка запросов к базе данных на языке SQL. Скрипт для создания базы данных.

    курсовая работа [161,8 K], добавлен 07.10.2013

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

    реферат [30,5 K], добавлен 22.02.2011

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

    реферат [57,1 K], добавлен 20.12.2010

  • Понятия основных компонентов базы данных Access. Таблицы, отчеты, макросы и модули, форма, запросы к базе и их виды. Типы данных. Создание базы данных "Кадры". Создание таблицы в режиме конструктора. Использование мастера подстановок для создания связей.

    курсовая работа [818,0 K], добавлен 10.03.2016

  • Основные конструкции структурированного языка запросов SQL. Изучение среды MS SQL Server Management Studio, проверка подлинности. Создание таблиц базы данных. Таблица specialit, сourse, group, discipline, account. Проектирование структур данных.

    лабораторная работа [963,2 K], добавлен 14.01.2016

  • Типы окружений для использования системы управления базами данных SQL Server. Клиент-серверная система. Использование SQL Server в качестве настольной системы. Требования к квалификации администраторов. Введение в структурированный язык запросов SQL.

    презентация [368,4 K], добавлен 14.10.2013

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

    дипломная работа [2,4 M], добавлен 02.06.2013

  • Программные продукты, используемые при проектировании базы данных. Разработка базы данных "Библиотека" с использование программного проекта Microsoft SQL Server. Создание таблиц, триггеров, пользователей, репликации, запросов, функций, процедур.

    курсовая работа [897,6 K], добавлен 21.11.2011

  • Выбор методологии проектирования и системы управления базами данных. Описание предметной области и проектирование физической структуры базы данных. Реализация проекта в MS SQL Server 2008. Построение инфологической модели. Ограничения целостности связи.

    курсовая работа [679,2 K], добавлен 22.01.2013

  • Иерархические, сетевые и реляционные модели данных. Различия между OLTP и OLAP системами. Обзор существующих систем управления базами данных. Основные приемы работы с MS Access. Система защиты базы данных, иерархия объектов. Язык программирования SQL.

    курс лекций [1,3 M], добавлен 16.12.2010

  • Анализ возможностей системы управления базами данных "Microsoft Access 2003". Создание базы данных, предназначенной для отражения деятельности аэропорта. Концептуальная и физическая модель базы данных. Создание таблиц, запросов, отчетов и главной формы.

    курсовая работа [1,8 M], добавлен 26.06.2013

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

    контрольная работа [365,4 K], добавлен 24.02.2015

  • Исследование характеристик и функциональных возможностей системы управления базами данных Microsoft Office Access. Определение основных классов объектов. Разработка базы данных "Делопроизводство". Создание таблиц, форм, запросов, отчетов и схем данных.

    реферат [1,3 M], добавлен 05.12.2014

  • Создание базы данных для информационной системы "Грузоперевозки". Анализ предметной области, разработка концептуальной и логической модели базы данных, с использованием средства MS Micrоsоft SQL Server 2005, реализация физического проектирования базы.

    курсовая работа [1,3 M], добавлен 01.07.2011

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

    курсовая работа [981,4 K], добавлен 05.11.2011

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.