Что такое бизнес правила программирование

Мы можем объяснить бизнес-правила двумя способами. Как правила внутри компании и как правила, которые применяются к данным в одном база данных.

Внутри компании

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

Бизнес-правила в базе данных

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

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

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

Идентификация

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

Бизнес-правила выводятся из требований, но не путайте их.

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

Написание бизнес-правил

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

1. У них есть уникальный идентификатор. Идентификатор может состоять из номера строки и отдела, к которому он относится.
2. Опишите только одну концепцию.
3. Они написаны на понятном языке.
4. Каждое бизнес-правило также происходит из одного источника.
5. Они однозначны, так что мы можем позже преобразовать их в тестовые случаи.

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

Запись и доступность

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

Бизнес-правила и процесс проектирования

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

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

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

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

Типы бизнес-правил

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

База данных ориентирована

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

Приложение ориентировано

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

Примеры бизнес-правил

Некоторые примеры типичных бизнес-правил и требований, из которых они возникают.

• Требование: Работник склада должен иметь возможность отгружать заказы, чтобы обеспечить покупателей их покупками. Бизнес-правило: дата отгрузки не может быть раньше даты заказа.
• Требование: работник аренды должен быть в состоянии назначить арендатору автомобиль, чтобы он мог водить машину. Бизнес-правило: арендатор не может арендовать более одного автомобиля одновременно.
• Требование: Покупатель должен иметь возможность размещать заказы без вмешательства других. Деловые правила: он может вести дела только с поставщиками из региона. Также он может самостоятельно совершать покупки на определенную сумму.
• Требование: продавцу разрешено предоставлять покупателям скидки, чтобы удовлетворить потребности покупателей. Бизнес-правила: Только постоянные клиенты могут получить скидку. Скидка также составляет максимум 15% на все покупки.

Механизм бизнес-правил (BRMS)

Если мы хотим оставаться гибкими как компания, механизм бизнес-правил может помочь нам управлять процессами принятия решений независимо от другого программного обеспечения для бизнеса. Система управления бизнес-правилами (BRMS) способна реализовать бизнес-логику в режиме реального времени, не завися от другого программного обеспечения. Таким образом, мы можем легко поделиться логикой принятия решений со всей организацией. Кроме того, BRMS гарантирует, что мы сможем последовательно применять сложный набор правил даже в более крупной организации.

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

Обсудить с нами LinkedIn.

Бизнес-правила (Business Rules Management) — это методические указания, которые обеспечивают правильность принятых решений при выполнении задач за счет того, что, устанавливают четкий порядок действий для заранее известных условий.

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

Большинство решений, принимаемых в бизнесе, не столь драматичны, но от это они не перестают быть менее комплексными. Даже бизнес-процесс найма сотрудников подразумевает несколько сценариев. Может ли чат-бот ответить на вопросы соискателя или нужна консультация HR-менеджера? Если HR-менеджер вынужден вмешаться, какие действия он должен совершить? Как соискатель и сотрудник отдела кадров должны взаимодействовать друг с другом, чтобы прийти к обоюдовыгодному результату?

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

Основой автоматизации выступают бизнес-правила — BRM (Business Rules Management). Для моделирования таких правил существуют специальные методологии и системы, т.н. BRMS (Business Rules Management Systems). Международный консорциум OMG даже предложил свой стандарт для описания бизнес-правил на основе семантики естественного языка — Semantics of Business Vocabulary and Business Rules.

Как бизнес-правила устроены изнутри?

С формальной точки зрения бизнес-правила состоят из двух элементов:

1. Условия — описывают ситуацию, в которой нужно предпринять определенные действия.
2. Действия — описывают, что должно произойти в ответ на заданные условия.

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

Сценарий 1

• условия — сумма товаров в корзине меньше 1000 рублей;
• действия — оформить платную доставку.

Сценарий 2

• условия — сумма товаров в корзине больше 1000 рублей;
• действия — оформить бесплатную доставку.

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

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

Поэтому появилась потребность в отдельных системах или инструментах для создания бизнес-правил с учетом их повторяемости, достоверности и применимости в системах автоматизации. Достоинство Comindware Business Application Platform как раз в том, что платформа поддерживает функциональность систем для управления бизнес-правилами на уровне сценариев. Их можно создавать в простом визуальном редакторе.

Что такое BRMS?

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

• самописные решения — не все BPMS поддерживают инструменты для работы с бизнес-логикой. Camunda — это по сути один процессный движок для программистов, к нему нужно еще добавить базу данных и процессную логику. Каждый раз переписывать строки кода, чтобы изменить алгоритм принятия решений, неудобно, поэтому можно взять готовый инструмент из репозитория.
• «лоскутная автоматизация» — функции автоматизации выполняют разные системы — CRM, SRM, RPA и далее по списку. Если логика процесса изменилась, то программисту придется лезть в каждую из этих систем по отдельности, что тоже неудобно.
• «убийственная сложность» — бизнес-правил может быть банально слишком много, как в случае с тем же андеррайтингом и скорингом, тогда не имеет смысла прятать бизнес-логику глубоко в программный код.

BRMS часто выступают в связке с BPMS, и еще в 2012 году считалось, что одно невозможно без другого. BPMS служили для проектирования процессов, а BRMS использовались для автоматизации отдельных задач. В Comindware Business Application Platform BRM изначально является частью платформы. Все сценарии автоматизации рассматриваются в контексте сквозных бизнес-процессов, а элементы управления бизнес-логикой реализованы в том числе на уровне Low-code настроек.

Преимущества Low-code автоматизации

В Comindware Business Application Platform бизнес-правила можно создавать без навыков программирования с помощью инструмента «Сценарии». Поэтому уже на этапе создания MVP, часть задач можно автоматизировать на основе алгоритмов, созданных самими пользователями.

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

BRM и пользователи-вандалы

Логично услышать возражение от ИТ-отдела:«А что если пользователи возьмут и все сломают. Ведь у нас бизнес-правила действуют по всей организации, поэтому меняя их только на локальном участке можно разрушить вообще всю бизнес-архитектуру». В этом есть доля правды, но Comindware Business Application Platform рассчитана на автоматизацию сквозных бизнес-процессов, за которые раньше отвечали разные системы. Это позволяет постепенно отказаться от BRMS (хотя бы на некоторых участках) и не хранить бизнес-правила отдельно от процессов. Вы можете сразу изменить алгоритм автоматизации и, протестировав процесс от начала до конца, увидеть результат.

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

Сделайте автоматизацию более прозрачной и управляемой с помощью Comindware Business Application Platform

Заказать демо

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Что такое бизнес-логика в программировании?

Что такое бизнес-логика в программировании?

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

• Бизнес-логика;
• Бизнес-правила;
• Бизнес-ограничение;
• Бизнес-операция;
• и т.д.

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

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

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

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

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

• Название книги
• Ф.И.О. автора
• Количество экземпляров данной книги
• Ф.И.О. читателя
• Дата рождения читателя
• Экземпляры книг, которые имеются у него на руках
• и т.д.

Где и как мы будем манипулировать этими данными в программе? Мартин Фаулер описывает три шаблона по организации бизнес-логики в проекте:

• Сценарий транзакций;
• Модуль таблицы;
• Модель предметной области.

Нас интересует последний пункт, поэтому данные будут храниться в таких классах-сущностях как  Читатель, Книга, Абонемент и т.д. Именно в них и будет содержаться большая чать бизнес-логики. Бизнес-логика реализует бизнес-правила. А что такое бизнес-правило?

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

Бизнес-правила разделяют примерно на шесть основных категорий:

1. Бизнес-термины – фундаментальная форма бизнес-правила. Это фразы, слова, аббревиатуры из предметной области. Обычно такие термины хранятся в документе под названием «бизнес глоссарий» или «словарь терминов». Примеры бизнес-терминов: читатель; книга; ISBN (англ. International Standard Book Number, сокращённо — англ. ISBN) — уникальный номер книжного издания; читательский абонемент – документ, где учитываются книги выданные читателю; и т.д.

2. Факты (facts) — это верные утверждения о бизнесе. Зачастую они описывают связи и отношения между важными бизнес-терминами. Факты также называют инвариантами — неизменными истинами о сущности данных и их атрибутах. Бизнес-правила во многих случаях могут ссылаться на определенные факты, однако последние обычно не преобразуются напрямую в функциональные требования к программному обеспечению. Сведения о сущности данных, важных для системы, применяют в моделях данных, создаваемых аналитиком или архитектором базы данных.

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

4. Активатором операции (action enabler) называется бизнес-правило, приводящее к выполнению каких-либо действий при определенных условиях. Человек может выполнять эти действия вручную. Иногда правило может управлять некоторыми функциями программы, благодаря которым приложение при выполнении определенных условий реализует нужную модель поведения. Выражение вида «Если <некоторое условие верно или наступило определенное событие>, то <что-то произойдет>»— это ключ, который описывает активатор операции.

5. Выводы (inference), иногда называемые предположительным знанием — это правила, устанавливающие новые реалии на основе достоверности определенных условий. Вывод создает новый факт на основе других фактов или вычислений. Выводы зачастую записывают в формате «если — то», применяемом также при записи бизнес-правил, активирующих операции. Тем не менее, раздел «то» вывода заключает в себе факт или предположение, а не действие.

//дата рождения читателя

DateTime dateOfBirth = new DateTime(1995, 3, 16);

//текущая дата

DateTime nowDate = new DateTime(2005, 3, 16);

int age = nowDate.Year — dateOfBirth.Year;

if (nowDate.Month < dateOfBirth.Month)

{

    age = age — 1;

}

else if (nowDate.Month == dateOfBirth.Month)

{

    if (nowDate.Day < dateOfBirth.Day)

    {

        age = age — 1;

    }

}

//реализация бизнес—логики

if (age < 7 || age > 21)

{

    throw new Exception(«Возраст должен быть от 7 до 21 года»);

}

else { //здесь регистрируем читателя в системе…}

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

Ссылки:

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

В первую очередь
бизнес-правила реализуют следующие
ограничения БД:

• задание допустимого
  диапазона значений;

• задание значения
  по умолчанию;

• требование
  уникальности значения;

• запрет пустого
  значения;

• ограничения
  ссылочной целостности.

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

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

При работе с
удаленными БД в архитектуре «клиент-сервер»
бизнес-правила можно реализовывать
также на сервере.

4.7. Словарь данных

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

Использование
словаря данных позволяет:

• ускорить процесс
  создания БД;

• облегчить изменение
  характеристик БД;

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

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

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

• Alignment
  —
  выравнивание;

• DisplayLabel
  — заголовок столбца (сетки DBGrid);

• Readonly
  — недоступность поля для редактирования;

• Required
  — требование обязательного ввода
  значения;

• Visible
  —
  видимость;

• DisplayFormat
  —
  формат отображаемого значения;

• MinValue
  —
  минимальное значение;

• MaxValue
  —
  максимальное значение.

Для
работы со словарем данных удобно
использовать программу SQL
Explorer.

Приложение

Таблицы
формата
dBase
и
Paradox

Delphi
не имеет своего формата таблиц, но
поддерживает как свои собственные два
типа локальных таблиц — dBase
и Paradox.
Каждая из этих таблиц имеет свои
особенности.

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

Основные
достоинства таблиц dBase:

• простота
  использования;

• совместимость с
  большим числом приложений.

В табл.
1
содержится список типов полей таблиц
dBase
IV.
Для каждого типа приводится символ,
используемый для его обозначения в
программе Database
Desktop
(создания и редактирования таблиц,
SQL-запросов
и запросов QBE),
a
также описание значений, которые может
содержать поле рассматриваемого типа.

Таблица
1

Типы
полей
таблиц
dBase
IV

Тип	Обозначение	Описание значения
Character	С	Строка символов. Длина не более 255 символов
Float	F	Число с плавающей точкой. Диапазон -10308 .. 10308. Точность 15 цифр мантиссы
Number	N	Число в двоично-десятичном формате BCD (Binary Coded Decimal)
Date	D	Дата
Logical	L	Логическое значение. Допустимы значение True (истина) и False (ложь). Разрешается использование прописных букв
Memo	M	Строка символов. Длина не ограничена. Символы хра­нятся в файле с расширением DBT
OLE	0	Данные в формате, который поддерживается технологи­ей OLE. Данные хранятся в файле с расширением DBT
Binary	В	Последовательность байтов. Длина не ограничена. Байты содержат произвольное двоичное значение, хранятся в файле с расширением DBT

Замечание

При
работе
с
таблицей
в
среде
программы
Database
Desktop
значения
полей
типа
Binary,
Memo
и
ole
не
отображаются.

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

• DBF
  —
  таблица с данными.

• DBT
  — данные больших двоичных объектов,
  или BLOB-данные
  (Binary
  Large
  OBject).
  К ним относятся двоичные, Memo-
  и OLE-поля.
  Memo-поле
  также
  называют полем комментариев.

• MDX
  — поддерживаемые индексы.

• NDX
  — индексы, непосредственно не
  поддерживаемые форматом dBase.
  При использовании таких индексов
  программист должен обрабатывать их
  само­стоятельно.

Имя
поля в таблице dBase
должно состоять из букв и цифр и начинаться
с бук­вы. Максимальная длина имени
составляет 10 символов. В имена нельзя
вклю­чать специальные символы и
пробел.

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

Таблицы
Paradox
являются достаточно развитыми и удобными
для создания БД. Можно отметить следующие
их достоинства:

• большое количество
  типов полей для представления данных
  различных ти­пов;

• поддержка
  целостности данных;

• организация
  проверки вводимых данных;

• поддержка парольной
  защиты таблиц.

Большой
набор типов полей позволяет гибко
выбирать тип для точного пред­ставления
данных, хранимых в базе. Например, для
представления числовой информации
можно использовать один из пяти числовых
типов. В табл. 2
содержится список типов полей для таблиц
Paradox
7. Для каждого типа приво­дится символ,
используемый для обозначения этого
типа в программе Database
Desktop,
и описание значений, которые может
содержать поле рассматривае­мого
типа.

Таблица
2

Типы
полей
таблиц
в
Paradox
7

Тип	Обозначение	Описание значения
Alpha	A	Строка символов. Длина не более 255 символов
Number	N	Число с плавающей точкой. Диапазон -10307 .. 10308. Точность 15 цифр мантиссы
Money	$	Денежная сумма. Отличается от типа Number тем, что в значении отображается денежный знак. Обо­значение денежного знака зависит от установок Windows
Short	S	Целое число. Диапазон -32 768 .. 32 767
LongInteger	1	Целое число. Диапазон -2 147 483 648 .. 2 147 483 647
BCD	#	Число в двоично-десятичном формате
Date	D	Дата. Диапазон 01.01.9999 до н.э. .. 31.12.9999
Time	T	Время
Timestamp	@	Дата и время
Memo	M	Строка символов. Длина не ограничена. Первые 240 символов хранятся в файле таблицы, остальные в файле с расширением MB
Formatted Memo	F	Строка символов. Отличается от типа Memo тем, что строка может содержать форматированный текст
Graphic	G	Графическое изображение. Форматы BMP, PCX, TIF, GIF и EPS. При загрузке в поле изображение преобразуется к формату BMP. Для хранения изо­бражения используется файл с расширением MB
OLE	0	Данные в формате, который поддерживается тех­нологией OLE. Данные хранятся в файле с расши­рением MB
Тип	Обозначение	Описание значения
Logical	L	Логическое значение. Допустимы значения True (истина) и False (ложь). Разрешается использова­ние прописных букв.
Auto- increment	+	Автоинкрементное поле. При добавлении к таблице новой записи в поле автоматически заносится зна­чение, на единицу большее, чем в последней до­бавленной записи. При удалении записи значение ее автоинкрементного поля больше не будет исполь­зовано. Значение автоинкрементного поля доступно для чтения и обычно используется в качестве клю­чевого поля
Binary	В	Последовательность байтов. Длина не ограничена. Байты содержат произвольное двоичное значение. Первые 240 байтов хранятся в файле таблицы, ос­тальные в файле с расширением MB
Bytes	Y	Последовательность байтов. Длина не более 255 байтов

Замечание

При
работе
с
таблицей
в
среде
программы
Database
Desktop
значения
полей
типа
Graphic,
Binary,
Memo
и
OLE
не
отображаются.

Имя
поля в таблице Paradox
должно состоять из букв (допускается
кириллица) и цифр и начинаться с буквы.
Максимальная длина имени составляет
25 симво­лов. В имени можно использовать
такие символы, как пробел, «#», «$»
и некото­рые другие. Не рекомендуется
использовать символы «.», «!»
и «|», т. к. они заре­зервированы
в Delphi
для других целей.

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

Замечание

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

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

Для
полей можно определить специальный
диапазон, в котором должны находиться
вводимые в них значения. Кроме того, для
каждого поля можно определить минимально
и максимально допустимые значения. При
попытке ввода в поле значения, выходящего
за допустимые границы, возникает
исключительная ситуация, значение не
вводится и содержимое поля не изменяется.
Например, для поля Salary
(Оклад) в качестве минимального значения
логично указать ноль, тем самым в это
поле запрещается ввод отрицательных
значений. Макси­мальное значение поля
Salary
зависит от организации, страны и от
других фак­торов.

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

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

Определенным
недостатком таблиц Paradox
является наличие относительного большого
количества типов файлов, требуемых для
хранения содержащихся в таблице данных.
При копировании или перемещении
какой-либо таблицы из одного каталога
в другой необходимо обеспечить копирование
или перемещение всех файлов, относящихся
к этой таблице. Файлы таблиц Paradox
имеют сле­дующие расширения:

• DB
  — таблица с данными;

• MB
  — BLOB-данные;

• РХ — главный
  индекс (ключ);

• XG*
  и YG*
  — вторичные индексы;

• VAL
  — параметры для проверки данных и
  целостности ссылок;

• TV
  и FAM
  — форматы вывода таблицы в программе
  Database
  Desktop.

Замечание

Указанные
файлы
создаются
только,
если
в
них
есть
необходимость;
конкрет­ная
таблица
может
не
иметь
всех
приведенных
файлов.

Кроме
названных файлов, при работе в сети для
контроля доступа к таблицам Paradox
используются файлы с расширением NET.

17

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

• Главная
• DataBase
• Основы
• Бизнес-правила управления базой данных

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

Бизнес-правила являются просто правилами управления БД и не имеют отношения к бизнесу как предпринимательству.

В первую очередь бизнес-правила реализуют следующие ограничения БД:

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

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

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

При работе с удаленными БД в архитектуре «клиент-сервер» бизнес-правила можно реализовывать также на сервере.

Табаков Юрий

Программист

Автор и редактор проекта CuBook.PRO. Главная задача, которую я ставлю перед собой – донести до начинающих программистов удобочитаемый материал. Буду рад выслушать замечания и предложения. Не забываем ставить оценки и делать репосты =)