Объекты и концепции базы данных

Таблицы

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

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

Видео

Макросы

Еще один из основных объектов Access – макросы. Они представляют собой последовательность действий, которые нужно выполнить при наступлении определенного события. Макросы создаются с помощью «Конструктора» и предусмотренных системой макрокоманд различного назначения.

Макрокоманды предназначены для импорта и экспорта данных, работы с другими объектами БД, установки фильтров и обработки записей таблицы и т. д. В качестве примера ниже показано добавление простого макроса, который запускается при нажатии на кнопку «Отмена» формы «Клиенты». Его задача состоит в том, чтобы просто закрыть форму, не сохраняя введенную в нее информацию.

Связи

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

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

LinkType
Id INTEGER Первичный ключ
Code CHAR(10) Краткое название связи
ItemName CHAR(30) Полное название связи, используется только для интерфейса

Например, сотрудник может быть связан с отделом, в котором он работает, связью типа «EMPDEPART» (сотрудник в отделе). В то же время он может быть связан с отделом связью «BOSS» (начальник отдела). Со сторонней фирмой сотрудник может быть связан как менеджер, а с документом — как его создатель. Сами связи хранятся в таблице:

Links
Id INTEGER Первичный ключ
ParentId INTEGER REFERENCES Objects(Id) Ссылка на первый из связываемых объектов
ChildId INTEGER REFERENCES Objects(Id) Ссылка на второй из связываемых объектов
TypeId INTEGER REFERENCES LinkType(Id) Ссылка на тип связи

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

А всех сотрудников отдела поставок можно найти запросом:

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

AllowedLinks
Id INTEGER Первичный ключ
ParentId INTEGER REFERENCES ObjType(Id) Ссылка на тип первого из связываемых объектов
ChildId INTEGER REFERENCES ObjType(Id) Ссылка на тип второго из связываемых объектов
TypeId INTEGER REFERENCES LinkType(Id) Ссылка на тип связи

На вставку и изменение записей в Links создается несложный триггер, который проверяет типы объектов для создаваемой связи и их допустимость по AllowedLinks. Поскольку разрешенные типы связей хранятся в таблице, мы получаем гибкий механизм для настройки БД под требования конкретной задачи. Если требуется задать новый тип связи между объектами — достаточно лишь добавить в AllowedLinks запись с этим типом связи и типами объектов.

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

Выбирая, какой тип объекта должен быть первым (ParentId), а какой вторым (ChildId) в связи, рекомендуется придерживаться единой системы. Для БД это безразлично, однако для уменьшения путаницы лучше в качестве первого выбирать объект, который бы оказался на стороне «один» отношения «один-ко-многим» при проектировании БД по классической методике. Если объекты связаны по принципу «многие-ко-многим», надо просто выработать для себя единую методику и в дальнейшем ей следовать.

Справочные ограничения целостности (Referential integrity constraints)

InterBase позволяет вам определять правила обеспечивающие целостность информации хранящейся в столбцах, эти првавила названы справочными ограничениями целостности (referential integrity constraints). Ограничения целостности управляют связями типа столбец-таблица (column-to-table) и таблица-таблица (table-to-table) а также проверкой ввода данных. Они выпонены через первичные ключи (primary keys), внешние ключи (foreign keys) и проверочные ограничения (check constraints). Обычно первичный ключ это столбец (или группа столбцов), которые используются, чтобы уникально идентифицировать строку таблицы. Внешний ключ это столбец, чьи значения должны соответствовать значениям столбца в другой таблице. Проверочные ограничения — ограничивают ввод данных определенным диапазоном или набором значений.

Например, таблица EMPLOYEE могла бы быть определена имеющей внешний ключ столбец DEPT_NO. Который определен в соответствии со столбцом номера отдела в таблице DEPARTMENT. Это гарантировало бы, что каждый служащий из таблицы EMPLOYEE связан с существующим отделом в таблице DEPARTMENT.

Объекты

Объект в нашей БД — понятие скорее логическое, его основное назначение — предоставить уникальный идентификатор, по которому его можно будет отличить. Кроме того, каждый объект обладает типом. Типы описываются таблицей:

ObjType
Id INTEGER Первичный ключ
Code CHAR(10) NOT NULL UNIQUE Краткое название типа. Используется в программе для поиска объектов данного типа
ItemName CHAR(30) Полное название типа, используется только для интерфейса

Типами объектов могут быть, например, «Фирма», «Сотрудник», «Товар».

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

Сами объекты хранятся в таблице:

Objects
Id INTEGER Первичный ключ
TypeId INTEGER REFERENCES ObjType(Id) Ссылка на тип объекта
ItemName CHAR(50) Название объекта

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

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

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

Макросы

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

Дополнительные сведения о макросах см. в статье Общие сведения о программировании в Access.

Триггеры (Triggers)

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

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

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

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

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

Теги

Adblock
detector