UML как программный язык

Дизайнеры рисуют диаграммы UML, которые затем компилируются непосредственно в исполняемый код. Таким образом UML становится исходным кодом программы. Само создание инструментов, реализующих этот подход, требует немалых усилий.

Нотации и метамодель

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

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

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

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

Метамодель – диаграмма, определяющая нотацию.

Метамодель помогает понять, что такое хорошо организованная, т.е. синтаксически правильная, модель.

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

Feature

Structural Feature

Behavioral

Feature

Parameter

* {ordered}

0..1

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

Рис. 1. Нотации и метамодель

· Activity – процедурное и параллельное поведение. Введено в UML 1;

· Class – классы, свойства и взаимоотношения. Введено в UML 1;

· Communication – взаимодействие между объектаими; акцент на связи.
В UML 1 называлась Сollaboration diagram;

· Component – структрура и связи компонентов. Введено в UML 1;

· Composite structure – декомпозиция класса во время выполнения. Новая
в UML 2;

· Deployment – размещение артефактов. Введено в UML 1;

· Interaction overview – смешение Sequence и Activity. Новая в UML 2;

· Object – пример конфигурации экземпляров. Неофициальная в UML 1;

· Package – иерархическая структура во время компиляции. Неофициаль­ная в UML 1;

· Sequence – взаимодействие между объектами. Акцент на последователь­ности. Введено в UML 1;

· State machine – способы изменения объекта различными событиями
в течение его жизненного цикла. Введено в UML 1;

· Timing – взаимодействие между объектами. Акцент на распределении во времени. Новая в UML 2;

· Use case – способы взаимодействия пользователей с системой. Введено
в UML 1.

Diagram

Structural

Diagram

Behavior Diagrma

Class Diagram

Composite

Structure Diagram

Object Diagram

Component

Diagram

Deployment

Diagram

Package Diagram

Activity Diagram

Use Case

Diagram

State Machine

Interaction

Diagram

Sequence

Diagram

Communication

Diagram

Interaction

Overview

Diagram

Timing Diagram

Рис. 2. Диаграммы UML

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

К основным понятиям UML относятся:

· Сущности – абстракции, являющиеся основными элементами модели;

· Отношения – связывают различные сущности;

· Диаграммы – группируют представляющие интерес совокупности сущностей.

Сущности

· структурные – статические части модели, соответствующие концептуальным или физическим элементам модели;

· поведенческие – динамические составляющие, описывающие поведение модели во времени и в пространстве;

· группирующие;

· аннотационные.

Структурные сущности

Класс (Class) – описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Реализует несколько интерфейсов.

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

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

Вариант использования (Use сase) – описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-либо определенного действующего лица (Actor).

Активный класс (Active class) – класс, объекты которого вовлечены в один или несколько процессов и могут инициировать управляющее воздействие.

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

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

Поведенческие сущности

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

Автомат (State machine) – поведение, определяющее последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакция на эти события.

Правильный UML

Правильный UML – хорошо форматированный в соответствии со спецификацией UML. Однако всё находится в реальном мире и всё не так просто. Каким языком считать UML? Предписывающим, как языки программирования, или описательным? Сложившееся понимание в ИТ индустрии на данный момент – рассматривать UML как описательный язык. И в этом случае, всё, что считается правильным в разрабатываемом конкретной группой программистов проекте, и есть правильный UML. Формально можно написать персональную метамодель, и тогда мы получим новый, абсолютно формально правильный UML. Нужны ли такие усилия?

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

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

• диаграмма классов;

• диаграмма последовательности действий;

• диаграмма объектов;

• диаграмма пакетов;

• диаграмма Use cases;

• диаграмма активностей.

Диаграмма классов

Это главная диаграмма, с которой работает программист. Она описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними. Также здесь показываются свойства и операторы класса
и ограничения, которые накладываются на способ, которым они связаны. UML использует термин «свойство» как общий термин для свойств и операторов (методов) класса. Следует различать свойства как поднабор операторов следующих контракту Java Beans – get <Имясвойства>, set <Имясвойства>.

Рис. 3. «Свойства» классов

Свойства

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

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

Атрибут – нотация, описывающая свойство текстовой строкой внутри изображения класса.

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

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

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

Рис. 4. Отношение зависимости

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

Payment

CashPayment

CreditPayment

CheckPayment

Например, понятия CashPayment, CreditPayment, CheckPayment очень похожи, и разумно организовать их в иерархию обобщения, чтобы подчеркнуть специализацию классов. Класс Payment представляет более общее понятие, а его подклассы – специализированные свойства.

Рис. 5. Отношение обобщения

Подкласс создается в случаях, если:

· имеет дополнительные атрибуты;

· имеет дополнительные ассоциации;

· ему соответствует понятие, управляемое, обрабатываемое или используемое способом, отличным от способа, определенного суперклассом или другими подклассами;

· представляет объекту поведение, которое отлично от поведе­ния, определяемого суперклассом или другими подклассами.

Отношение обобщения реализуется при наследовании классов.

AdminMessage

«interface»

AbstractMessage

Реализацией (Realization) называется отношение между классификаторами (классами, интерфейсами), при котором один описывает контракт (интерфейс сущности), а другой гарантирует его выполнение.

Рис. 6. Отношение реализации

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

Рис. 7. Отношение ассоциации

Одним из вариантов отношения ассоциации является агрегация.

Факультет

Кафедра

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

 

Рис. 8. Отношения коллективной агрегации и композиции

Множественность

Presentation::EmployeeCustomer

-

ID: int

-

pageBean: PageBean

«property get»

+

getPageBean(): PageBean

«property set»

+

setPageBean(PageBean): void

«Event»

+

validateCard(AbstractCard): boolean

Presentation::PageBean

~

age: int

#

colorOfHair: int

-

lastName: String

-

middleName: String

-

name: String

+

weight: int

«property get»

+

getName(): String

«property set»

+

setName(String): void

+pageBean

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

Рис. 9. Множественность

/* пример # 1: множественность отношений между классами:

EmployeeCustomer.java */

public class EmployeeCustomer {

private int ID = 0;

private PageBean pageBean = null;

 

public int getID() {

return this. ID;

}

public void setID(int newID) {

this. ID = newID;

}

public PageBean getPageBean() {

return this. pageBean;

}

}

AbstractCard

Presentation::

CreditCard

Presentation::

Wallet

+Owner

Owns

+Participant

1..*

Двунаправленная ассоциация

Рис. 11. Двунаправленная ассоциация

/* пример # 2: взаимная видимость классов: Wallet.java, CreditCard.java */

public class Wallet {

private List<CreditCard> creditCards = null;

public void addCreditCard(CreditCard newCreditCard) {

creditCards.add(newCreditCard);

}

}

public class CreditCard {

private Wallet wallet = null;

public void setWallet(Wallet newWallet) {

this. wallet = newWallet;

}

}

Операторы

Наиболее очевидный пример оператора – метод класса. То есть операторы можно рассматривать как действия, которые класс знает, как выполнить. Хотя getter и setter для свойства тоже являются методами, как правило, их не указывают на диаграммах, так как их наличие очевидно в соответствии с конкрактом Java Beans. Обычно их указывают на диаграммах в случае несимметричного использования, например, класс может иметь только getter-методы по каким-то специфическим причинам.

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

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

Приложение 4

БАЗЫДАННЫХ И ЯЗЫК SQL

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

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

№	Наименование	Ед. изм.	Цена	Кол-во
	Кирпич	штука
	Краска	литр
	Шифер	лист
…	…	…	…	…
	Гвоздь	штука
	Кабель	метр

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

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

Базовые функции СУБД:

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

Реляционные СУБД

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

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

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

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

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

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

Пример логически взаимосвязанных таблиц:

Сотрудники
Табельный №	Фамилия	Должность	№ отдела
	Иванов	Начальник
	Петров	Инженер
	Сидоров	Менеджер

 

Отделы
№ отдела	Наименование
	Производственный отдел
	Отдел продаж

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

• Первичный ключ (или главный ключ, primary key, PK). Представляет собой столбец или совокупность столбцов, значения которых однозначно идентифицируют строки. В данном примере первичным ключом в таблице “Сотрудники” является столбец “Табельный №”, ибо в одной организации не бывает сотрудников с одинаковыми табельными номерами. Очевидно, что в таблице “Отделы” первичным ключом является столбец, содержащий номер отдела;
• Вторичный (или внешний ключ, foreign key, FK). Столбец или совокупность столбцов, которые в данной таблице не являются первич­ными ключами, но являются первичными ключами в другой таблице. В рассматриваемом примере столбец “№ отдела” таблицы “Сотрудники” содержит вторичный ключ, с помощью которого может быть установлена логическая взаимосвязь строк таблицы с соответствующими строками таблицы “Отделы”.

Если какая-либо таблица содержит вторичный ключ, то она считается логически взаимосвязанной с таблицей, содержащей соответствующий первичный ключ. В общем случае эта связь имеет характер “один ко многим” (одному значению первичного ключа может соответствовать несколько значений вторичного, пример – отдел № 15). Возможны варианты, когда вторичный ключ входит в состав первичного ключа. Всё зависит от предметной области, которую описывает модель. В общем случае СУБД ничего “не знает” о логической взаимосвязи таблиц модели. При обращении к СУБД с запросом пользователь должен в явном виде указать условия связывания двух таблиц. В нашем примере условие будет выглядеть примерно так: “Сотрудники”.”№ отдела” = “Отделы”.”№ отдела”. Следовательно, в процессе написания запроса возможно связать две таблицы по любым произвольным полям (не только по первичным и вторичным ключам), которые
в принципе могут быть сравнимы друг с другом. В этом случае связь носит характер “многие ко многим”. Иногда это бывает необходимо делать при написании сложных и специфических запросов, но в общем случае не рекомендуется и свидетельствует об ошибках при проектировании логической модели БД.

В некоторых реляционных СУБД возможно создавать так называемые ограничения целостности, которые в том числе контролируют взаимосвязь между PK и FK. Так, СУБД заблокирует попытки удалить запись из таблицы, на первичный ключ которой “ссылаются” вторичные ключи в других таблицах. И наоборот – нельзя будет внести в поле вторичного ключа значение, отсутствующее в первичном ключе логически взаимосвязанной таблицы. Но это – только средство поддержания целостности данных и защиты от ошибок. Даже при наличии таких конструкций СУБД всё равно требует от пользователя логического связывания таблиц в явном виде при написании запросов к данным.

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

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

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

…

Иванов, 15 отдел, начальник

…

Правильно:

Фамилия	Должность	№ отдела
Иванов	Начальник

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

№ отдела	Должность	Отдел	Количество сотрудников
	Начальник	Производственный отдел
	Инженер	Производственный отдел
	Начальник	Отдел продаж
	Менеджер	Отдел продаж

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

	Отделы
	№ отдела	Наименование
		Производственный отдел
		Отдел продаж
Структура
№ отдела	Должность	Количество сотрудников
	Начальник
	Инженер
	Начальник
	Менеджер

Кстати, это пример случая, когда вторичный ключ (“№ отдела”) одновремен­но является частью первичного (“№ отдела”, “Должность”).

Следствие: если в таблице первичный ключ состоит из одного столбца, то эта таблица автоматически соответствует 2НФ (при условии соответствия и 1НФ).

Третья нормальная форма гласит: таблица соответствует первым двум НФ
и все неключевые атрибуты зависят только от первичного ключа и не зависят друг от друга. Пример несоответствия 3НФ:

Сотрудники
Табельный №	Фамилия	Оклад	Наименование отдела	№ отдела
	Иванов		Производственный отдел
	Петров		Производственный отдел
	Иванов		Отдел продаж

Очевидно, что неключевые атрибуты “Наименование отдела” и “№ отдела” логически взаимосвязаны друг с другом, в то время как комбинация фамилия-отдел-оклад имеет смысл только в сочетании с табельным номером сотрудника (предположим, что в организации работают два Иванова-однофамильца в разных отделах). Решение может быть следующим:

Сотрудники
Табельный №	Фамилия	Оклад	№ отдела
	Иванов
	Петров
	Иванов

 

Отделы
№ отдела	Наименование
	Производственный отдел
	Отдел продаж

 

Язык SQL

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

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

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

“Общение” пользователя с СУБД осуществляется с помощью специальных утилит, которые обычно входят в комплект поставки СУБД. В частности, у Oracle эта утилита называется SQL*Plus, а у MS SQL Server – Query Analyzer. Любая из них способна как минимум принять от пользователя SQL-команду, отправить ее на выполнение ядру СУБД и отобразить на экране результат операции. Вот как выглядит экран Oracle SQL*Plus:

Рис. 1. Интерактивная утилита

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

Команды SQL

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

Базовый вариант SQL содержит порядка 40 команд (часто еще называемых запросами или операторами) для выполнения различных действий внутри СУБД.

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

SELECT TabNum FROM Employees WHERE Salary>500

где:

• SELECT – глагол (“выбрать”);
• FROM, WHERE – ключевые слова (“откуда”, “где”);
• Employees – имя таблицы;
• TabNum, Salary – имена столбцов таблицы.

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

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

Команды определения структуры данных
(Data Definition Language – DDL)

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

Пример некоторых DDL-команд:

Команда	Описание
CREATE TABLE	Создать новую таблицу
DROP TABLE	Удалить существующую таблицу
ALTER TABLE	Изменить структуру существующей таблицы

Команды манипулирования данными
(Data Manipulation Language – DML)

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

Примеры DML-команд:

Команда	Описание
SELECT	Извлечь данные из таблицы
INSERT	Добавить новую строку данных в таблицу
DELETE	Удалить строки из таблицы
UPDATE	Изменить информацию в строках таблицы

 

Команды управления транзакциями
(Transaction Control Language – TCL)

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

TCL-команды:

Команда	Описание
COMMIT	Завершить транзакцию и зафиксировать все изменения в БД
ROLLBACK	Отменить транзакцию и отменить все изменения в БД
SET TRANSACTION	Установить некоторые условия выполнения транзакции

Команды управления доступом (Data Control Language – DCL)

DCL-команды управляют доступом пользователей к БД и отдельным объектам:

Команда	Описание
GRANT	Разрешить доступ
REVOKE	Отменить доступ

Работа с командами SQL

Извлечение данных, команда SELECT

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

SELECT [ DISTINCT ]<список столбцов>

FROM <имя таблицы>[ JOIN <имя таблицы> ON <условия связывания>]

[ WHERE <условия выборки>]

[ GROPUP BY <список столбцов для группировки>[ HAVING <условия выборки групп>] ]

[ ORDER BY <список столбцов для сортировки>]

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

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

SELECT TabNum FROM Employees

SELECT TabNum,Name FROM Employees

Звездочка (*) на месте списка столбцов обозначает все столбцы таблицы:

SELECT * FROM Employees

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

SELECT Employees. Name,Departments. Name FROM …

Ключевое слово DISTINCT

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

SELECT DISTINCT Position FROM Employees

Секция FROM, логическое связывание таблиц

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

Employees

⇐ Предыдущая24252627282930313233Следующая ⇒

Поделиться: