Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Web-аппликации в Интернет-маркетинге: проектирование, создание и применение

Структура базы данных

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

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

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

Для реализации типа связи «многие-ко-многим» используется дополнительная таблица-«связка», в которой хранятся пары ключей связанных объектов.

Иногда возникает необходимость организовать связь между экземплярами объектов одного типа, тогда также создается дополнительная таб- лица-«связка» по аналогии с отношением типа «многие-ко-многим», только в этом случае пара ключей ссылается на одну и ту же таблицу. Часто это используется для построения структуры типа дерева, которая широко используется для хранения структур типа меню.

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

  • 1) корневой — самый верхний узел дерева, у которого нет родителя;
  • 2) промежуточный — узел, у которого есть родитель и потомки;
  • 3) лист — узел самого нижнего уровня дерева, у которого нет потомков.

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

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

Для обозначения типов связи на схемах (рис. 6.5, подготовлено автором) используются следующие типы связей: «один-к-одному», «один-ко- многим», «многие-ко-многим».

При именовании таблиц целесообразно придерживаться следующих правил:

  • 1. Основные таблицы называть по типу объекта, данные которого в ней хранятся, например Article — для статьи, Book — для книг и т.д.
  • 2. Вспомогательные таблицы, связывающие два типа объектов, как сводное имя двух таблиц, разделенное значком «_»(подчеркивание). На-
Типы связей в БД

Рис. 6.5. Типы связей в БД

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

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

Схема создания БД для нового проекта

Рис. 6.6. Схема создания БД для нового проекта

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

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

  • 1) объединение всех словарей разработки в один. Под словарем понимается множество пар <описание, код>, ориентированных на конкретное функциональное использование. Подробно этот элемент технологии будет рассмотрен ниже;
  • 2) введение типа объекта в связи объектов.

Рассмотрим конкретный пример. При наличии в БД объектов типа «Статья», «Книга», «Фильм» и другие у каждого из них есть авторы, которые связаны с основными объектами отношением «один-ко-многим», т.е. необходимы таблицы: «авторы статей», «авторы книг», «авторы фильмов» и т.д. При этом объединение таблиц, характеризующих основные объекты, обычно нецелесообразно, так как объекты описываются различными списками атрибутов (полей таблиц), авторы представляют собой один и тот же объект с заданной структурой. Использование трех таблиц связи между основным объектом и «Автором» необходимо для возможности отбора всех авторов статей или фильмов. Однако можно объединить эти таблицы, если ввести дополнительно в каждую из них запись-«связку» понятие «тип объекта», т.е. таблица будет состоять из трех позиций, например:

Тип основного объекта

Ключ основного объекта

Ключ объекта «Автор»

Статья

01

01

Статья

02

01

Статья

03

02

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

Тип объекта

Объект типа 1

Объект типа 2

Статья

СтатьяСИ

АвторСИ

Статья

Статья01

Автор02

Баннер

БаннерСН

Автор02

Баннер

Баннер02

Автор02

При использовании СУБД типа MS SQL запросы к БД осуществляются частично при помощи хранимых процедур (Store Procedure). Их использование во многих случаях ускоряет время выполнения действий с БД и повышает безопасность web-аппликации. Однако при их большом количестве разработчику трудно оперировать их списком за счет неразвитости средств их ведения в СУБД. Это может быть, например, отсутствие средств фильтрации и сортировки при визуализации списка процедур и невозможности разделения их на группы. Поэтому аналогично таблицам БД целесообразно применять к ним унифицированную систему именования, которая может включать следующие элементы группирования:

  • • префикс;
  • • основная функция;
  • • объект обработки.

Группировка с элементом «префикс» может выделять источник использования хранимой процедуры при наличии в web-аппликации различных функциональных компонентов. Основная функция определяет назначение хранимой процедуры: добавление (Add), удаление (Delete), обновление (Update) и др. Объект обработки выделяет, к какому основному объекту предметной области (таблице) относится данная процедура: подписка (Subscription), посылка (Dispatch) и т.д. Последовательность этих элементов может быть произвольной и определяется разработчиком. Две последние схемы группировки (основная функция или объект обработки) используются либо для группирования по функциональности, тогда будет несколько больших групп при ограниченном количестве действий и большом разнообразии объектов (основная функция, объект обработки) или много небольших групп действий по каждому объекту (объект обработки, основная функция), например:

Группировка по функциональности

Группировка по объектам

AddSubscrption

SubscriptionAdd

AddDispatch

SubscriptionEdit

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

Таким образом, при проектировании БД систем интернет-маркетинга целесообразно придерживаться двух правил:

  • 1) использовать унифицированную систему именования таблиц и хранимых процедур;
  • 2) минимизировать количество таблиц в БД.
 
Посмотреть оригинал
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >
 

Популярные страницы