Clipper Tools II

- оконные функции (псевдографика)

- управление режимами видеоадаптера

- последовательный интерфейс (RS-232)

- обработка строк (кодирование, шифрование, файлы, упорядочение потока символов)

- числовые функции (математика)

- дисковые функции (файловая система)

- поддержка печати (очередь заданий на печать)

- время и даты

- системные функции (окружение MS DOS)

- поддержка сети (Novell)

- непосредственное чтение портов ввода-вывода

2.4.7. СУБД Microsoft Access 97

Традиционная СУБД + реляционный интерфейс. Объектами в MICROSOFT ACCESS называют все, что может иметь имя. Это таблицы, запросы, формы, отчеты, макросы и модули. Определим эти объекты:

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

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

Устанавливается так же один или несколько индексов с целью увеличения скорости доступа к данным.

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

Запрос - объект, который позволяет пользователю получить нужные данные из одной или нескольких таблиц. Для создания запроса Вы можете использовать QBE (запрос по образцу) или инструкции SQL. Вы можете создавать запросы на выбор, обновление, добавление или удаление данных. С помощью запросов Вы можете создавать новые таблицы, используя данные из одной или нескольких таблиц, которые уже существуют.

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

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

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

Модуль - объект, содержащий программы (процедуры или функции) на языке Access VBA (Visual Basic for Applications). Эти процедуры или функции можно использовать для сложных вычислений, которые не могут быть представлены последовательностью простых математических вычислений, т.е. используются для выполнения действий, которые превышают возможности стандартных макросов. Обычно процедура или функция связывается с некоторым событием, таким как нажатие кнопки в активной форме или отчете. Модули могут быть независимыми объектами, содержащими функции, которые можно вызывать из любого места приложения, но они могут быть и непосредственно привязаны к отдельным формам или отчетам для реакции на проходящие в них те или иные изменения. Желательно использование модулей сократить до минимума, ограничиться вычислениями или событиями, которые не удается выполнить при помощи макросов. В Word и Excel для создания макросов предусмотрен специальный макрорекодер, а в Access типа специализированного конструктора, которые благополучно справляются с построением необходимых модулей, корректировать которые при необходимости проще, чем писать новые, в прочем это дело вкуса либо это продиктовано необходимостью.

Взаимосвязи основных объектов в Microsoft Access.

В Microsoft Access база данных включает в себя все объекты, связанные с хранимыми данными. Ниже приведен рисунок (рис.01а) взаимосвязи основных объектов базы данных: таблиц, запросов, форм, отчетов, макросов и модулей. В таблице хранятся данные, которые вы можете извлекать с помощью запросов. Используя формы можно выводить данные на экран и изменять их. Формы и отчеты могут использовать данные непосредственно из таблиц или через запросы. Для выполнения необходимых вычислений и преобразования данных, запросы могут использовать встроенные функции или функции, написанные на языке VBA (Visual Basic for Application), например, делая запрос на выборку, в качестве условий отбора можно через построитель выбрать функцию (как встроенную, так и свою пользовательскую), т.е. запросы могут вызывать модули. События, связанные с формами или отчетами могут запускать макросы или функции и процедуры, написанные на VBA. Событие – это любое изменение состояния объекта. Например, событием является открытие/закрытие формы, изменение состояния элемента управления (например, нажатие кнопки) и т.п. Для обработки события вы можете создать макрос или процедуру VBA(модуль). При помощи макросов и модулей можно изменять ход выполнения приложения, открывать, фильтровать и изменять данные в формах и отчетах, выполнять запросы и создавать новые таблицы.

3. Функции и типовая организация СУБД

3.1. Трехуровневая архитектура современных БД

· External level (внешний уровень)

o User view (пользовательский интерфейс)

· Conceptual level (концептуальный уровень)

o Global description of the database entities (глобальное описание сущностей)

o Data types (типы данных)

o Relationships and constraints (связи и конструкции)

· Internal level (внутренний уровень)

o Physical storage structure

3.1.1. External level (пользовательский интерфейс)

· 1) Different views of the database (различные представления БД)

· 2) Different representations of same data in different views (различные представления одних и тех же данных)

· 3) Views and calculations not stored (просмотр и расчет без сохранения в БД)

· 4) Entities, attributes and relationships of interest to the user (конкретные объекты, атрибуты, связи)

3.1.2. Conceptual level (концептуальный уровень)

· 1) Independence from storage constraints (абстрактные конструкции)

· 1-1) Represents:

o entities, attributes, relationships & constraints (сущности, атрибуты, связи, объекты)

o information about the data (информация о данных)

· 2) Logical structure of the database (логическая структура БД)

· 2-1) What is stored and its relationships (что хранится и существующие связи)

· 3) security and integrity information (информация о безопасности)

3.1.3. Internal level (внутренний уровень)

· 1) Physical implementation (физические устройства)

· 2) How the data are stored (как хранятся данные)

· 2-1) Concerns:

o Allocation of space for data

o Record description and placement

· 3) Data structure, file organization, interface with the Operating System

· 4) Compression and encryption of data

3.2. Состав БД:

А) База данных содержит помимо собственно данных (data) - метаданные (Metadata), представляющие описание структуры хранимых данных. Эти метаданные иногда называют - “Data dictionary” or system catalog. (Словарь данных или системный каталог). Это описание обеспечивает две цели:

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

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

- поддержание логически согласованного набора файлов;

- обеспечение языка манипулирования данными;

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

- реально параллельная работа нескольких пользователей.

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

3.3. Функции СУБД (5)

3.3.1. Непосредственное управление данными во внешней памяти (менеджер данных – Data Manager)

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

3.3.2. Управление буферами оперативной памяти (менеджер буферов – Buffers Manager)

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

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

3.3.3. Управление транзакциями (Менеджер транзакций – transaction manager)

Транзакция - это выделенная последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.

Понятие транзакции необходимо для поддержания логической целостности БД. Пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Пример реализации в Clipper – операция списания (проводка – платежный документ – основные средства (выплаты) – сотрудники – договор – контрагентский договор – состояние счетов (сальдо). – подпрограмма F_VER

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

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

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

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

3.3.4. Журнализация (менеджер журнала – Journal Manager)

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

Обычно рассматриваются два возможных вида аппаратных сбоев:

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

- «жесткие» сбои, характеризуемые потерей информации на носителях внешней памяти.

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

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

Основная стратегия - "упреждающая" запись в журнал (так называемого протокола Write Ahead Log - WAL). Смысл: запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

2) Восстановление множества транзакций. При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.

3) Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

3.3.5. Поддержка языков БД

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

- язык определения схемы БД (SDL - Schema Definition Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. Clipper – программа DBU + встроенные команды + встроенные функции. В иерархических (сетевых) СУБД – элементы контроля целостности.

- язык манипулирования данными (DML - Data Manipulation Language). DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Clipper – встроенные команды + встроенные функции.

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

- 1) средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными.

- 2) специальные средства определения ограничений целостности БД. Обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код. Пример: Clipper – операция списания.

- 3) специальные операторы языка SQL позволяют определять так называемые представления БД ( отличие от Clipper ). Фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне. Конкретный пользователь видит – не реальные таблицы, а представления (реальные запросы + права доступа: поля, записи, таблицы)

- 4) авторизация доступа к объектам БД производится также на основе специального набора операторов SQL – иерархия полномочий. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.

3.4. Типовая организация современной СУБД

Разные версии СУБД разных фирм в принципе отличаются по организации. Но! Логически в современной реляционной СУБД можно выделить:

- 1) ядро СУБД (часто его называют Data Base Engine),

- 2) компилятор языка БД (обычно SQL),

- 3) подсистему поддержки времени выполнения,

- 4) набор утилит.

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

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

Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными ( что это означает? ), т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия (отличие от Clipper или компиляторов C, C++). Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Применяются достаточно сложные методы оптимизации операторов. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде.

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

Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например:

- загрузка и выгрузка БД,

- сбор статистики,

- глобальная проверка целостности БД и т.д.

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

4. Общие понятия реляционного подхода к организации БД. Основные концепции и термины

В данном разделе рассматриваются на сравнительно неформальном уровне:

· основные понятия реляционных баз данных;

· существо реляционной модели данных.

Основной целью лекции является демонстрация простоты и возможности интуитивной интерпретации этих понятий. Необходимо учитывать, что реляционная модель данных сформировалось в результате анализа опыта создания многочисленных конкретных баз данных в 60-70хх годах. Поэтому сами элементы реляционной модели являются абсолютно абстрактными т.е. ни как не связаны ни с какой конкретной предметной областью. Это и было одной из основных целей разработчиков. Но на практике большинство этих понятий легко иллюстрируется (сводится) к обычным житейским понятиям.

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

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации (рис.2).

4.1.1. Тип данных

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

· символьных, числовых данных, битовых строк,

· специализированных числовых данных (таких как "деньги"),

· специальных данных (дата, время, временной интервал)

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

В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги".

4.1.2. Домен

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

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

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

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

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

4.1.3. Атрибут, схема отношения, схема БД

Прежде чем переходить к другим понятиям – введем понятие «Схема отношения» и «Схема БД»

Атрибут – определение домена для выбранного отношения.

Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа данных)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.

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

Схема БД ( в структурном смысле) - это набор именованных схем отношений.

4.1.4. Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Т.е. фактически – это отдельная строка (запись) таблицы. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Попросту говоря, кортеж - это набор именованных значений заданного типа.

Отношение - это множество кортежей, соответствующих одной схеме отношения.

Обычным житейским представлением:

· таблица - схема отношения;

· заголовок таблицы – отношение;

· строки таблицы - кортежи;

· столбцы таблицы - имена атрибутов;

· набор таблиц – схема БД.

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

Дата добавления: 2015-11-14