Шехтман В.Е. Базы данных, SQL и все такое. Курс лекций

Подождите немного. Документ загружается.

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ

НОВОКУЗНЕЦКИЙ ФИЛИАЛ-ИНСТИТУТ

КЕМЕРОВСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА

В. Е. Шехтман

Базы данных, SQL и все такое

Курс лекций

Новокузнецк 2006

ББК 32.973.26-018.2я73

Ш54

УДК 004.65 (042.4)

Рецензенты:

Кафедра автоматизации производственных процессов Кузбасской государственной

педагогической академии (зав. кафедрой доктор технических наук, профессор,

Веревкин В. И.)

Кандидат технических наук, доцент Белоусов П. Г.

Шехтман В. Е.

Ш54 Базы данных, SQL и все такое [Текст]: курс лекций / В. Е. Шехтман; НФИ

КемГУ. - Новокузнецк, 2006. – 195 с.

ISBN 5-8353-419-6

Учебное пособие рассматривает теоретические основы и практику проектирования,

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

традиционными темами (такими как реляционная теория и инфологическое моделирование)

пособие стремится раскрыть и новые направления: объектно-ориентированные, дедуктивные и

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

включает примеры, иллюстрирующие теоретический материал.

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

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

информации и управления», «Прикладная информатика в экономике», «Прикладная

математика и информатика», «Информационные системы в экономике» при изучении курсов

«Базы данных», «Современная технология программирования SQL», а также «Базы данных и

экспертные системы».

Печатается по решению методического совета НФИ КемГУ

ISBN 5-8353-419-6

университета, 2006

Введение

Учебное пособие предназначается для студентов всех форм обучения

специальностей «Автоматизированные системы обработки информации и управления»

(220200) (квалификация – инженер), в дальнейшем АСОИУ, «Прикладная информатика

(по областям)» (351400) (квалификация – информатик с областью применения в

экономике), в дальнейшем ПИЭ, «Прикладная математика и информатика» (010200)

(квалификация – математик, системный программист), в дальнейшем ПМИ. В нем

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

«Базы данных» (АСОИУ, ПИЭ), «Базы данных и экспертные системы» (в части баз

данных) (ПМИ), которые включены в циклы общепрофессиональных дисциплин

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

специальностей. Кроме того, пособие охватывает и курс «Современная технология

программирования SQL», включенный в цикл дисциплин специализации национально-

регионального (вузовского) компонента специальностей ПИЭ и ПМИ в Новокузнецком

филиале-институте КемГУ. В целом материал пособия соответствует требованиям

Государственных образовательных стандартов высшего профессионального

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

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

специальности, поэтому ниже описаны схемы использования пособия для

соответствующих специальностей.

Методы и понятия баз данных являются фундаментом построения

информационных и информационно-управляющих систем самого широкого профиля.

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

предприятиями и промышленными установками; но без них не обходятся и

информационные системы, с которыми человек сталкивается на каждом шагу – в

системах связи, на транспорте, в больницах…

В настоящей работе сделана попытка рассмотрения этой важной области с

единых позиций с целью дать читателю последовательное и, по возможности,

целостное представление о круге вопросов и решений, которые составляют суть

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

Очевидно, что в рамках одного учебного пособия сложно охватить все

многообразие методов, техник и приложений современных баз данных, а тем более

сложно довести их владение до профессионального уровня. Поэтому оно представляет

собой, скорее, «карту» по рассматриваемой тематике, пользуясь которой

заинтересованный читатель может продолжить изучение предмета и

совершенствоваться в нем самостоятельно. При этом автор постарался выдержать

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

технологии через теоретический фундамент (реляционная и инфологическая модели,

теория нормализации) к практике приложений – языку SQL и программно-

техническому воплощению. В ходе движения по этому пути базовые концепции

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

Еще одна цель данного пособия вытекает из того обстоятельства, что

существующие учебные пособия несколько отстают от сегодняшнего уровня развития

тематики баз данных

. Некоторые новые направления вообще не представлены или

представлены недостаточно в учебной литературе, например: объектно-

ориентированные базы данных, системы бизнес - анализа на основе многомерной

модели данных и хранилища данных, дедуктивные базы данных,

полуструктурированные данные на основе XML, извлечение знаний из данных. Эти

См. например [8], рекомендуемый в качестве учебника по дисциплине ―Базы данных‖ для

вычислительных специальностей ВУЗов.

темы, при всей их актуальности, рассматриваются только в большом количестве

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

трудно доступных монографий. Пособие содержит введение в этот новый круг идей и

методов баз данных.

Предполагается, что к моменту чтения соответсвующего курса студенты уже

прослушали курс дискретной математики, овладели техникой программирования в

одной из распространенных сред (например, Borland Delphi) и имеют представление об

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

(например, Microsoft Access). Эти требования удовлетворяются обычно к третьему-

четвертому курсу обучения на факультете информационных технологий.

Возможны различные схемы освоения материала пособия. Для курса ―Базы

данных и экспертные системы‖ подходит изложение с первого по седьмой разделы,

затем (быть может частично) раздел 9, и затем разделы 12-14, 17. При этом, для того

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

может, несколько раньше чем в пособии освоить язык SQL, а несколько позже - все,

что касается нормализации. Для курса ―Базы данных‖ возможна такая

последовательность: разделы с 1 по 7, частично 9 и 12, затем 13, 15, 16. Для курса

―Современная технология программрования SQL‖ изложение начинается с обзорного

повторения раздела 6, затем разделы с 7 по 17 в полном объеме (можно опустить или

сократить материал раздела 14). Для курса ―Базы данных и СУБД‖ можно

придерживаться ―естественного‖ т. е. заданного автором, порядка изложения, варьируя

его объем по мере надобности.

К данному пособию примыкает «Руководство по выполнению лабораторных

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

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

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

подробное рассмотрение вопросов организации СУБД, теории и техники оптимизации

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

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

настоящего пособия, при этом они входят в цикл дисциплин специализации

федерального компонента образовательного стандарта специальности

«Математическое обеспечение и администрирование информационных систем»

(351500) (квалификация математик-программист), обучение по которой пока только

планируется.

Несколько слов по поводу названия… Автор желал бы отразить в нем широту и,

отчасти, новизну тем, затронутых в пособии. Некоторым оправданием ему может

послужить известная монография [21]. Относясь к совершенно иной области знания,

она, тем не менее, является образцом целостного, последовательного и

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

были разбросаны по множеству источников и не воспринимались как целое. Автор

сознает, что ни в коей мере не приблизился к ее достоинствам, но желание идти в этом

направлении служило стимулом в работе.

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

1.1 Предпосылки баз данных

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

– это выполнение численных расчетов, которые слишком долго или вообще

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

применения вычислительной техники является наличие сложных алгоритмов

обработки, применяемых к сравнительно простым по структуре данным, объѐм

которых невелик. Развитие этой сферы привело к прогрессу в решении сложных

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

алгоритмов.

Вторая сфера – это использование вычислительной техники в автоматических и

автоматизированных информационных системах. Информационная система – это

программно-аппаратный комплекс, обеспечивающий

 надежное хранение информации в памяти компьютера;

 выполнение специфических для данного приложения преобразований

информации и вычислений;

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

Такие системы обычно оперируют большими объѐмами информации, имеющей

сравнительно сложную структуру. В качестве примера таких систем можно привести

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

предприятиях, системы управления промышленными агрегатами и т. д.

В начальный период развития второй сферы применения вычислительной

техники организацией данных занимались прикладные программисты. Каждая

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

данными. Пока на ЭВМ решались отдельные, не связанные друг с другом задачи, такое

положение было естественным. Кроме того, в качестве хранилища данных на первых

порах достаточно было использовать файлы операционной системы.

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

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

Комплекс программ призван управлять тем или иным сложным объектом, обработкой

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

обращаться к одним и тем же данным, формировать единую информационную модель

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

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

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

и управление данными отдельно от конкретных прикладных задач. Тогда любые

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

хранилища данных совершенно единообразным способом. Отсюда следует первое

требование, которое предъявляется к системе управления базами данных (СУБД):

обеспечить независимый от прикладной задачи интерфейс по управлению

данными.

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

дополнительной предпосылкой и стимулом для неѐ явилось возникновение внешнего

запоминающего устройства большого объѐма и высокой скорости доступа – жѐсткого

диска. Все существовавшие до того внешние запоминающие устройства накладывали

слишком большие ограничения либо по скорости (магнитные ленты), либо по объѐму

информации (магнитные барабаны), либо по тому и другому (перфокарты,

перфоленты).

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

управления ими. Они были осознаны как специфические инструменты для решения

специализированных задач по хранению, обработке, поддержанию целостности данных

больших объѐмов и сложной структуры. Тогда же зародилась и соответствующая

терминология.

1.2 Пример базы данных

Представим простую информационную систему, поддерживающую учет

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

покупает некоторые товары по низкой цене большими партиями, размещает их на

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

мелкими партиями; по мере продажи пополняет запасы товаров в магазинах со склада.

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

 выдавать списки товаров на складе;

 выдавать список поставщиков;

 отражать перемещение товаров от поставщика на склад и в магазин со

склада;

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

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

определенный период;

 необходимо иметь возможность получить общую сумму стоимости

товара по цене продажи и по цене закупа на складе.

Начнем с анализа того, что должно быть зафиксировано в системе при учете

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

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

Рисунок 1.1 – Общий вид документа о поступлении товара от поставщика

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

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

 номер документа;

 имя поставщика;

 дата поставки;

 перечень товаров с указанием их количества, цены закупа и цены

продажи.

Акт приема

684

Поставщик

Тесса ООО

Дата

16.04.2003

Наименование

Вес

ящика,

кг

Кол-во

ящиков,

шт.

Цена

закупочная,

руб.

Цена

продажная,

руб.

Груша "Анжу"

512

635,00

645,00

Груша "Пэкхем"

448

630,00

640,00

Груша "Конференс"

240

570,00

585,00

Виноград "Red Globe"

красный

8.2

515,00

510,00

Редис

2.5

190,00

200,00

Перечень поставляемых товаров представляет пример набора данных. Каждая

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

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

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

относящимися к разным колонкам. Так, первая запись состоит из пяти полей, имеющих

следующие значения: Груша "Анжу"; 18; 512; 635,00; 645,00. Видно, что значением

поля может быть не только число, но и цепочка символов. Заголовок колонки,

например Вес ящика, кг, называется именем поля. Поле Кол-во ящиков

последовательно принимает значения:

512

448

240

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

определяющего тип поля. Так, Кол-во является полем целого типа, поскольку в него

можно заносить только целые числа, Цена закупочная – поле действительного типа, а

поле Наименование – поле строчного типа.

Попробуем разобраться, какие наборы данных нужно создать для отражения

информации из приемного акта.

Имена, адреса и прочие реквизиты поставщиков должны храниться в наборе

данных, который мы будем называть ПОСТАВЩИКИ. Имена и типы полей этого

набора данных:

ПОСТАВЩИКИ:

НОМЕР_ПОСТ Целый

ИМЯ Строковый

АДРЕС Строковый

ИНН Строковый

На каждого поставщика в этом наборе данных заведена одна запись. Поле

НОМЕР_ПОСТ введено искусственно, каждой записи соответствует ее уникальный

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

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

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

можно однозначно найти требуемую запись. В наборе данных ПОСТАВЩИКИ

очевидно нельзя в качестве возможного ключа использовать поле ИМЯ по упомянутой

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

ИМЯ и АДРЕС, т. к. невероятно, чтобы у двух фирм с одинаковым названием был бы и

одинаковый адрес. Другим возможным ключом является поле НОМЕР_ПОСТ. Еще

одно поле, подходящее на роль возможного ключа – ИНН (идентификационный номер

налогоплательщика), т. к. он присваивается государственными органами и является

уникальным в рамках всей страны. Правда, иностранные поставщики могут не иметь

такого реквизита. Таким образом, в наборе данных ПОСТАВЩИКИ имеются три

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

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

качестве такового выберем НОМЕР_ПОСТ.

В нашей системе необходимо иметь и набор данных, в котором будут содержаться

сведения о товарах.

ТОВАРЫ:

НОМЕР_ТОВАРА Целый

НАЗВ Строковый

ОПИСАНИЕ Строковый

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

записываться содержимое приемных актов. Вообще говоря, можно сохранить

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

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

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

связанные с переменностью количества полей, можно разрешить путем усложнения

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

информация из приемного акта может заноситься в два набора данных –

ЗАГОЛОВКИ_ПРИЕМ_АКТ и СОДЕРЖАНИЕ_ПРИЕМ_АКТ. В первом хранится

информация, не зависящая от товаров, получаемых по приемному акту, например,

название поставщика, дата поставки и т. д. Во втором – информация о поставляемых

товарах. Вот примерная структура этих наборов данных:

ЗАГОЛОВКИ_ПРИЕМ_АКТ:

НОМЕР_ПРИЕМ_АКТ Целый

НОМЕР_ПОСТ Целый

ДАТА Временной тип

СОДЕРЖАНИЕ_ПРИЕМ_АКТ:

НОМЕР_ПРИЕМ_АКТ Целый

НОМЕР_ТОВАРА Целый

ВЕС Действительный

КОЛ_ВО Целый

ЦЕНА_ЗАКУП Действительный

ЦЕНА_ПРОД Действительный

В зависимости от наших потребностей хотелось бы иметь две возможности: из

набора данных СОДЕРЖАНИЕ_ПРИЕМ_АКТ выбирать строки одного приемного акта

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

сравнения цен на один товар от разных поставщиков). Следовательно, надо иметь

возможность доступа к этому набору данных как по номеру приемного акта

НОМЕР_ПРИЕМ_АКТ так и по товару НОМЕР_ТОВАРА. Что касается набора данных

ПОСТАВЩИКИ, то для него надо иметь возможность поиска записи по имени

поставщика ИМЯ и по номеру поставщика НОМЕР_ПОСТ. Для того чтобы получить

общую сумму, на которую были поставлены товары одним из поставщиков, система

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

посчитать соответствующую сумму.

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

текущие остатки товаров на складе. Ясно, что они определяются тем, какие и сколько

товаров были получены от поставщиков и какие и сколько товаров были отправлены в

магазины. Вот примерная структура такого набора данных:

ОСТАТКИ:

НОМЕР_ТОВАРА Целый

КОЛ_ВО Целый

Если мы попытаемся использовать файлы операционной системы для реализации

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

соответствующих наборов данных, приведенных выше. При работе с этими файлами

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

вставку новых записей, изменение полей записей, вычеркивание записей. В этом в

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

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

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

НОМЕР_ПОСТ из набора данных ЗАГОЛОВКИ_ПРИЕМ_АКТ и не допускала вставки

в этот набор данных записей со значением поля НОМЕР_ПОСТ, отсутствующем в

наборе данных ПОСТАВЩИКИ. Это так называемая ссылочная целостность. (Такое

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

которых заранее занесены в набор данных ПОСТАВЩИКИ.) Другой пример: в файле

ОСТАТКИ данные должны изменяться всякий раз, как только выполняется ввод нового

акта приемки (и документа, соответствующего факту отправки товара в магазин - этот

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

хотя помнить о нем надо).

При решении такой задачи требуется поддержка знаний о том, как один набор

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

данные в файлах. Эти добавочные знания называются метаданные. Для решения этой

и подобных проблем система должна будет содержать метаданные, в которые входят

знания о структуре и смысле каждого поля каждого набора данных (например, поле

НОМЕР_ПОСТ в файле ЗАГОЛОВКИ_ПРИЕМ_АКТ и поле НОМЕР_ПОСТ в файле

ПОСТАВЩИКИ означают одно и то же). Также система должна ―понимать‖, что в ряде

случаев изменение информации в одном файле должно автоматически вызывать

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

Например, если вводится новый приемный акт о приходе товара от поставщика, то

необходимо добавить записи в файл ОСТАТКИ (или модифицировать имеющиеся там

записи), чтобы отразить новые значения фактических остатков соответствующих

товаров на складе.

Понятие поддержки целостности данных или (согласованности данных) является

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

поддерживает согласованное хранение информации в нескольких наборах данных,

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

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

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

управления базами данных. Итак, второе требование к СУБД:

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

Но это еще не все, что обычно требуют от СУБД. Представим себе алгоритм, с

помощью которого можно получить общую сумму, на которую были куплены товары у

поставщика по имени X. Понятно, что подобные этому алгоритмы придется

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

некоторую нетривиальную последовательность циклических действий над

содержимым записей нескольких наборов данных. Было бы гораздо проще, если бы

СУБД позволяла сформулировать запрос, освобождая программиста от необходимости

описывать алгоритм в явном виде на некотором языке программирования. Языки,

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

Например, на языке SQL, который является основным языком запросов в современных

системах баз данных, наш запрос можно было бы выразить в форме:

SELECT SUM(КОЛ_ВО * ЦЕНА_ЗАКУП)

FROM СОДЕРЖАНИЕ_ПРИЕМ_АКТ,

ЗАГОЛОВКИ_ПРИЕМ_АКТ,

ПОСТАВЩИКИ

WHERE

СОДЕРЖАНИЕ_ПРИЕМ_АКТ. НОМЕР_ПРИЕМ_АКТ =

ЗАГОЛОВКИ_ПРИЕМ_АКТ.НОМЕР_ПРИЕМ_АКТ

AND ЗАГОЛОВКИ_ПРИЕМ_АКТ.НОМЕР_ПОСТ =

ПОСТАВЩИКИ.НОМЕР_ПОСТ

AND ПОСТАВЩИКИ.ИМЯ=‗X‘

Таким образом, при формулировании запроса СУБД позволит не задумываться о

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

информация о том, что поле НОМЕР_ПОСТ является ключевым для файла

ПОСТАВЩИКИ, а НОМЕР_ПРИЕМ_АКТ - для файла ЗАГОЛОВКИ_ПРИЕМ_АКТ, и

система сама воспользуется этим. Отсюда третье требование к СУБД:

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

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

Однако всего перечисленного все еще не достаточно для ―возведения‖ нашей

системы в ―ранг‖ баз данных. Представим, что в нашей информационной системе

выполняется операция ввода нового приемного акта о приходе товаров. Следуя

требованиям согласованного изменения файлов, система вставила новую запись в файл

СОДЕРЖАНИЕ_ПРИЕМ_АКТ и собиралась модифицировать запись файла

ОСТАТКИ, но в этот момент произошло аварийное выключение питания. Очевидно,

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

состоянии – строка в СОДЕРЖАНИЕ_ПРИЕМ_АКТ имеется, но соответствующая ей

корректировка файла ОСТАТКИ не произведена. ―Настоящие‖ СУБД берут заботу о

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

заботиться о корректности состояния базы данных. Отсюда вытекает четрвертое

требование:

система должна обеспечить надежное хранение данных даже несмотря на

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

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

нескольких операторов) работу с нашей базой данных. Если опираться только на

использование файлов, то для обеспечения корректности на все время модификации

любого из файлов доступ других пользователей к этому файлу должен быть

блокирован. Таким образом, ввод приемного акта может затормозить ввод документа о

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

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

ОСТАТКИ. Настоящие СУБД обеспечивают гораздо более тонкую синхронизацию

параллельного доступа к данным. Поэтому пятым требованием к СУБД будет:

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

пользователям.

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

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

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

вводить данные о приходе товара на склад от поставщика, другие только анализировать

историю продаж и взаимоотношений с поставщиками. Поэтому СУБД должна

осуществлять ограничение прав пользователей с целью обеспечения

безопасности и секретности данных.

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

База данных (БД) – именованная совокупность данных, отражающая состояние

объектов и их отношений в рассматриваемой предметной области. В нашем примере

предметной областью являлась торговая фирма, а именованные данные –