Студопедия — Гайдамакин Н. А. 7 страница
Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Гайдамакин Н. А. 7 страница






Поле-атрибут Y функционально зависит от поля-атрибута X, если любому значению Х всегда соответствует в точности одно значение Y. К примеру, атрибут «ФИО» функционально зависит от атрибута «Таб.№», т. е. каждому значению атрибута «Таб.№» соответствует только одно значение атрибута «ФИО». Другим примером является функциональная зависимость поля «Кабинет» от поля «Фамилия», так как обычно один сотрудник имеет рабочее место только в одном кабинете. Легко убедить­ся, что в таблице, находящейся в первой нормальной форме, все неключевые атрибуты функционально зависят от ключа таб­лицы.

Вторая нормальная форма основывается на понятии пол­ной функциональной зависимости. Функциональная зависи­мость неключевого атрибута от составного ключа таблицы называется полной, если он функционально зависит в целом от составного ключа, но не зависит отдельно от любой части со­ставного ключа. В примере, приведенном на рис. 3.4, значение поля-атрибута «Фамилия» определяется только значением поля «Лич.№ сотр.», которое является частью составного ключа таб­лицы, и, следовательно, функционально полной зависимости неключевого поля-атрибута «Фамилия» от составного ключа нет. В полной функциональной зависимости от составного клю­ча находится поле-атрибут «Награда», так как только комбина­ция значений полей «Лич.№ сотр.» и «Условное наименование мероприятий...» определяет конкретное значение поля «Награ­да».

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

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

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

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

Рчс. 3.5. Пример приведения таблицы из первой во вторую нор­мальную форму

В таблицах, находящихся во второй нормальной форме, большинство аномалий, присущих первой скорме, устранено. Вместе с тем по определенным атрибутам также могут сохра­няться многочисленные ситуации дублирования данных. Так, например, в приведенном на рис. 3.5 примере происходит нео­правданное дублирование информации о служебном телефоне «11 22 33», так как атрибут «Сл. тел.» фактически зависит не от атрибута «Лич.№ сотр.»», а от атрибута «Кабинет».* Иначе говоря, наблюдается цепочка функциональной зависимости атрибутов «Лич. № сотр.» — «Кабинет» — «Сл. тел.», а функцио­нальная зависимость атрибута «Сл.тел.» от атрибута «Лич. № сотр.» является лишь логическим следствием такой це­почки зависимостей. В таких ситуациях говорят о транзитив­ной зависимости атрибута «Сл. тел.» от атрибута «Лич. № сотр.».

* В большинстве жизненных ситуаций в одной комнате для сотрудников уста­новлен один общий телефон.

 

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

Для преобразования из второй в третью нормальную фор­му таблицу-отношение разделяют на две или более проекции так, чтобы конечные поля-атрибуты в цепочках транзитивной зависимости вынести в отдельные таблицы, связав разделив­шиеся части таблицы внешними ключами по полям-атрибутам, находящимся внутри цепочек транзитивной зависимости. На рис. 3.6 проиллюстрирован процесс приведения таблицы из вто­рой в третью нормальную форму путем разделения цепочки транзитивной зависимости «Лич.№ сотр.» — «Кабинет» — «Сл. тел.». Внутреннее в этой цепочке поле-атрибут «Кабинет» стало соответственно внешним ключом в первой таблице и пер­вичным ключом во второй таблице.

Рис. 3.6. Пример приведения таблицы в третью нормальную форму

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

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

Рис. 3.7. Пример приведения таблицы из третьей нормальной формы в форму Бойса-Кодда

В данной таблице имеются два детерминанта — («Лич. № сотр.», «Операция») и («Фамилия», «Операция»), от каждого из которых функционально полно зависит поле-атри­бут «Мероприятие».

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

* Поэтому иногда нормальную форму Бойса-Кодда считают частным случаем третьей нормальной формы.

 

Таблица, приведенная на рис. 3.7, не удовлетворяет требо­ванию нормальной формы Бойса-Кодда, так как если устано­вить ключом детерминант («Лич.№ сотр.», «Операция»), то поле-атрибут «Фамилия» будет функционально зависеть от ча­сти составного ключа (от поля «Лич.№ сотр.») и нарушатся тре­бования второй нормальной формы. Следствием та кой ситуа­ции является дублирование данных по полям-атрибутам «Лич. № сотр.» и «Фамилия».

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

Встречаются также случаи, требующие «улучшения» и нор­мальной формы Бойса—Кодда. Такие ситуации связаны с многозначной зависимостью атрибутов. В таблице-отношении с полями-атрибутами X, Y, Z существует многозначная зависи­мость атрибута Y от атрибута Х тогда и только тогда, когда любое значение из множества Y, соответствующее паре значе­ний атрибутов Х и Z, зависит только от значения Y. Для приме­ра рассмотрим таблицу на рис. 3.8. При этом будем считать, что каждый сотрудник, привлеченный к какой-либо операции, в обязательном порядке участвует во всех проводимых в рам­ках данной операции мероприятиях. В этом случае единствен­но возможным ключом является совокупность всех трех полей атрибутов (каждый сотрудник может участвовать в разных опе­рациях, в одной операции может участвовать несколько сотруд­ников).

Рис. 3.8. Пример декомпозиции таблицы из нормальной формы Бойса-Кодда в четвертую нормальную форму

Так как имеется единственный возможный составной ключ, то данная таблица автоматически находится в нормальной фор­ме Бойса—Кодда. При этом имеется многозначная зависимость поля-атрибута «Фамилия» от поля-атрибута «Операция» (для любой пары значений атрибутов «Операция»—«Мероприятие» значение атрибута «Фамилия» фактически определяется толь­ко значением атрибута «Операция» при сформулированном выше условии участия каждого сотрудника автоматически во всех мероприятиях данной операции). Аналогично имеется мно­гозначная зависимость поля-атрибута «Мероприятия» от поля-атрибута «Операция». В такой ситуации для внесения инфор­мации о новом сотруднике, вовлекаемом в какую-либо опера­цию, придется добавить столько строк-кортежей, сколько мероприятий проводится в рамках данной операции.

Подобные аномалии устраняет четвертая нормальная фор­ма. Таблица-отношение находится в четвертой нормальной форме тогда и только тогда, когда в случае существования мно­гозначной зависимости атрибута Y от атрибута Х все осталь­ные атрибуты функционально зависят от атрибута X.

Приведение таблицы в четвертую нормальную форму ос­новывается на теореме Фейджина, в которой доказывается воз­можность проецирования без потерь* таблицы с атрибутами X, Y, Z в две таблицы с атрибутами X, Y и X,Z, когда существу­ет многозначная зависимость атрибута Y от атрибута X. Про­цесс декомпозиции проиллюстрирован на рис. 3.8.

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

 

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

Таблица-отношение может находиться в четвертой нор­мальной форме, но когда в ней имеется зависимость соединения, могут возникать аномалии при операциях добавления/уда­ления строк-кортежей. Для примера рассмотрим таблицу, при­веденную на рис. 3.9. Ключом таблицы является совокупность всех трех полей-атрибутов, так как сотрудник может входить в состав разных групп и участвовать в разных мероприятиях, каж­дое из которых может проводиться разными группами. В таб­лице нет детерминантов, отсутствуют функциональные и мно­гозначные зависимости, т. е. таблица находится в четвертой нор­мальной форме. Тем не менее в данной таблице нельзя удалить информацию по участию Бонда в мероприятии «Контакт», не удалив при этом вообще информацию о мистере Бонде в таб­лице. Нельзя также добавить строку-запись о вхождении мис­тера Бонда еще и в группу «F», если при этом он не участвовал ни в одном мероприятии.

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

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

Приведение таблицы в пятую нормальную форму осуще­ствляется путем ее декомпозиции сразу на несколько таблиц отношений. Если предположить, что в таблице, представлен­ной на рис. 3.9. имеется зависимость соединения по составным атрибутам «Фамилия»-«Группа», «Фамилия»-«Мероприятие», «Группа»-«Мероприятие»,* то, разбив таблицу на три проекции по соответствующим полям-атрибутам, можно удовлетво­рить требованиям пятой нормальной формы и устранить отме­ченные аномалии.

* Наличие зависимости соединения является нетривиальным предположением, основывающимся в большинстве случаев на эвристических соображениях, т.е. в дан­ном случае на уверенности, что при соединении трех таблиц «Фамилия»-«Группа», «Фамилия»-«Мероприятие» и «Группа»-«Мероприятие» не произойдет каких-либо потерь пли появления лишних данных относительно исходной таблицы.

 

Из-за нетривиальности зависимости соединения пятая нор­мальная форма практически не используется.

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

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

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

 

Для повышения эффективности схемно-структурного про­ектирования банков данных на рынке программных средств СУБД появился специальный класс программ, называемых CASE-cucmeмами. * Наиболее известными из них являются Designer 2000 компании «Оrасlе», ErWin компании «LogicWorks», PowerBulder компании «PowerSoft». Такие системы предостав­ляют проектировщику банка данных средства концептуально­го проектирования баз данных на основе техники семантичес­кого моделирования. При этом широко используются средства визуализации определения и описания информационных объек­тов, связей и их атрибутов, что делает процесс проектирования максимально наглядным и позволяет проектировщику сосре­доточиваться на смысловом аспекте структуры банка данных. Разработанная таким образом концептуальная схема банка дан­ных транслируется CASE-системой в схему соответствующе­го реляционного банка, избавляя проектировщика от утомитель­ных процедур «ручного» перевода концептуальной (семанти­ческой) схемы в реляционную.

* Computer Aided Software Engineering—системы автоматизированного проек­тирования.

 

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

Вопросы и упражнения

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

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

3. Учет материальных средств по подразделениям предусматривает их закрепление за определенными сотрудниками. Выделите основные объекты-сущности предметной области и отношения меж­ду ними для концептуального проектирования банка данных АИС, автоматизирующей учет матсредств и материально ответственных. Изобразите средствами ER-модели концептуальную схему.

4. При концептуальном проектировании банка данных АИС, авто­матизирующей ведение Табеля рабочего времени сотрудников организации, выделены следующие объекты-сущности:

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

5. При проектировании таблицы «Преподаватели» выделены следу­ющие атрибуты — ФИО, Кафедра (Истории, Математики, Инфор­матики), Должность (Зав. кафедры, Профессор, Преподаватель, Ассистент), Ученая степень (Кандидат наук. Доктор наук). Уче­ное звание (Старший научный сотрудник, Доцент, Профессор, Ака­демик), Пед. стаж. Определите и обоснуйте для каждого атрибу­та тип поля и другие параметры (обязательность заполнения, словарно-списочный характер и тип словаря, индексируемость и тип индекса, возможные ограничения целостности данных). Вы­берите из имеющихся атрибутов или предложите дополнительно ключ таблицы.

6. При проектировании таблицы «Автомобили» базы данных «За­пасные части» выделены следующие атрибуты — Модель, Про­изводитель (ВАЗ, АЗЛК, ГАЗ, ИЖМаш, УАЗ), Категория (Легко­вой, Грузовой, Специальный), Грузоподъемность, Год начала производства, Год прекращения производства, Фото. Определите и обоснуйте для каждого атрибута тип поля и другие параметры (обязательность заполнения, словарно-списочный характер и тип словаря, индексируемость и тип индекса, возможные ограниче­ния целостности данных). Выберите из имеющихся атрибутов или предложите дополнительно ключ таблицы.

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

• «Сотрудник»— Taб_№, ФИО, Должность, Подразделение;

• «Подразделение»— №№, Наименование, Руководитель;

«Пропуск»— Ta6_№_comp., №_пропуска, Дни, Время, Кто подписал.

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

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

• «Подразделения» — №№, Наименование, Профиль (Произ­водственно-технологический, Сбытовой, Снабженческий, Организационно-управленческий);

• «Операции»— Код, Наименование, Описание;

«Комплектующие» — Код, Наименование, Тип (Крепеж, Электрооборудование, Резинотехнические изделия), Количе­ство, Минимально необходимое количество на складе.

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

9. Приведите к первой нормальной форме следующую ненормали­зованную таблицу (в жирной рамке ключ таблицы):

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

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

4. Ввод, обработка и вывод данных в фактографических АИС

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

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

4.1. Языки баз данных

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

Однако такой подход приводил к «самостийности», уни­кальности каждой конкретной СУБД и созданной на ее основе автоматизированной информационной системы. В результате для реализации любой функции по вводу, обработке или выво­ду данных требовались квалифицированные программисты для написания специальных программ на алгоритмических языках высокого уровня (в 70-х годах ФОРТРАН, КОБОЛ и др.), «зна­ющих» особенности структуры и способы размещения данных во внешней и оперативной памяти. В итоге работа с базами дан­ных осуществлялась через посредника в виде квалифицированного программиста, «переводящего» информационные потреб­ности пользователя в машинный код,* что схематично иллюст­рируется на рис. 4.1.

* В этом плане примечателен афоризм Чарльза Бахмана, который метко подме­тил, что «программист— это штурман в море данных». Статью по поводу присужде­ния ему премии Тьюринга за пионерские работы в области технологий баз данных он так и назвал — «The Programmer As Navigator» (Программист как штурман).[ Вацкевич Д. Стратегии клиент/сервер, – К.: Диалектика, 1996. С. 216.]

 

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

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

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

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

В практику эти идеи впервые претворились в ходе реали­зации проекта System R (1975-1979 гг.) с участием еще одного известного специалиста по базам данных Криса Дейта. В ходе проекта System R был создан язык SEQUEL, трансформировав­шийся впоследствиив язык структурированных запросов SQL (Structured Query Language).* При этом дополнительно к воз­можностям формирования «вопросов» к базе данных пользо­вателю также решено было предоставить и возможность опи­сания самой структуры данных, ввода данных и их изменения.

* Добавим также, что примерно в то же время в компании IBM был создан еще один реляционный язык—QBE (Query-By-Example), т. е. язык запросов по образцу, применявшийся впоследствии во многих коммерческих системах обработки таблич­ных данных и послуживший идеологической основой для создания визуальных «кон­структоров» запросов в современных СУБД.

 

Идеи языка SQL оказались настолько плодотворными, что он быстро завоевал популярность и стал широко внедряться в создаваемых в конце 70-х и в 80-х годах реляционных СУБД. Однако плодотворность идей языка SQL в отличие от первона­чального замысла проявилась вовсе не в том, что на нем стали «разговаривать» с базами данных пользователи, не являющие­ся профессиональными программистами. Язык SQL, в конеч­ном счете, позволил, как уже отмечалось, отделить низкоуров­невые функции по организации структуры и обработке дан­ных от высокоуровневых функций, позволяя при создании и эксплуатации банков данных сосредоточиваться на смысловом, а не техническом аспекте работы с данными.

Быстрое и массовое распространение языка SQL в реляци­онных СУБД к середине 80-х годов привело фактически к при­нятию его в качестве стандарта по организации и обработке данных. В 1986 г. Американским национальным институтом стандартов (ANSI) и Международной организацией по стандар­тизации (ISO) язык был стандартизирован де-юре, т. е. признан стандартным языком описания и обработки данных в реляци­онных СУБД. В 1989 г. ANSI/ISO была принята усовершенство­ванная версия SQL — SQL2, а в 1992 г. третья версия — SQL3.

Язык SQL относится к так называемым декларативным (непроцедурным) языкам программирования. В отличие от про­цедурных языков (С, Паскаль, Фортран, Кобол, Бейсик) на нем формулируются предложения (инструкции) о том, «что сде­лать», но не «как сделать, как получить». Машина данных в СУБД исполняет роль интерпретатора и как раз строит ма­шинный код, реализующий способ получения результата, задаваемого SQL-инструкциями.

Язык SQL состоит из двух частей:

языка описания (определения) данных — DDL (Data Definition Language);

языка манипулирования данными — DML (Data Manipulation Language).

Синтаксис SQL-инструкций включает:

название инструкции (команду);

предложения, определяющие источники, условия опера­ции;

• предикаты, определяющие способы и режимы отбора за­писей, задаваемых предложениями;

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

Структуру SQL-инструкций можно разделить на две основ­ные части, схематично представленные на рис. 4.3.*

* Квадратные скобки, как это общепринято, означают необязательность элемента

 

Рис. 4.3. Структура SQL-инструкций.

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

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

Перечень SQL-инструкций разделяется по частям языка SQL.

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

CREATETABLE... — создать таблицу;

CREATEINDEX... — создать индекс;

ALTERTABLE... — изменить структуру ранее создан­ной таблицы;

DROP... — удалить существующую таблицу и базы данных.

В структуре инструкций CREATETABLE и ALTERTABLE важную роль играет предложение CONSTRAINT (создать огра­ничения на значения данных) со следующими установками — NOT NULL (не допускаются нулевые, точнее «пустые» значе­ния по соответствующему полю, иначе говоря, определяется поле с обязательным заполнением), AUTOINC (поле с инкре­ментальным, т. е. последовательно возрастающим с каждой но­вой записью, характером значений) и PRIMARY KEY (опреде­ление для поля уникального, т. е. без повторов, индекса, что в результате задает режим заполнения данного поля с уникаль­ными неповторяющимися по различным строкам значениями).

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







Дата добавления: 2015-08-12; просмотров: 2442. Нарушение авторских прав; Мы поможем в написании вашей работы!



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

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

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

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

Анализ микросреды предприятия Анализ микросреды направлен на анализ состояния тех со­ставляющих внешней среды, с которыми предприятие нахо­дится в непосредственном взаимодействии...

Типы конфликтных личностей (Дж. Скотт) Дж. Г. Скотт опирается на типологию Р. М. Брансом, но дополняет её. Они убеждены в своей абсолютной правоте и хотят, чтобы...

Гносеологический оптимизм, скептицизм, агностицизм.разновидности агностицизма Позицию Агностицизм защищает и критический реализм. Один из главных представителей этого направления...

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

Правила наложения мягкой бинтовой повязки 1. Во время наложения повязки больному (раненому) следует придать удобное положение: он должен удобно сидеть или лежать...

ТЕХНИКА ПОСЕВА, МЕТОДЫ ВЫДЕЛЕНИЯ ЧИСТЫХ КУЛЬТУР И КУЛЬТУРАЛЬНЫЕ СВОЙСТВА МИКРООРГАНИЗМОВ. ОПРЕДЕЛЕНИЕ КОЛИЧЕСТВА БАКТЕРИЙ Цель занятия. Освоить технику посева микроорганизмов на плотные и жидкие питательные среды и методы выделения чис­тых бактериальных культур. Ознакомить студентов с основными культуральными характеристиками микроорганизмов и методами определения...

Studopedia.info - Студопедия - 2014-2024 год . (0.013 сек.) русская версия | украинская версия