Принципы логического проектирования БД

(инфологической) модели предметной области (по результатам предпроектного обследования);
выбор типа БД

и проектирование логической (даталогической) модели БД;
выбор СУБД и проектирование физической модели БД;
разработку программных модулей и процедур для работы с приложением БД;
разработку процедур для администрирования БД.

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

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

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

выходных форм, анкеты, опросы, приказы, руководства)

Отображаются в моделях…

ER)
Комплексные - ARIS (cтандарт де-факто, признан среди разработчиков и пользователей), UML.

Инструменты для создания моделей

Computer Associates AllFusion (ERWin, BPWin, Paradigm Plus) - IDEF0, ER, DFD
Rational Rose - UML
ARIS Toolset - DFD, UML, eEPC, Industrial and Office process, Value-added chain diagram (VAD)
Microsoft Visio - IDEF0, ER, DFD, WorkFlow, UML, Basic Flowchart, Cross- Functional Flowchart (SwimLine)
Design/IDEF - IDEF0, DFD
Case – аналитик - IDEF0, DFD

Статус официального стандарта получили языки IDEF и UML.

начале 70-х годов и получившем название SADT (Structured Analysis &

Design Technique — метод структурного анализа и проектирования).
Программа интегрированной компьютеризации производства (ICAM), предложенная ВВС США, была направлена на увеличение производительности в промышленности посредством повсеместного внедрения компьютерных технологий. Подход, лежащий в основе программы ICAM, заключается в разработке структурных методов, способствующих применению компьютерных технологий в промышленном производстве. Программа ICAM выявила потребность в более совершенных способах обмена информацией и методах анализа производственных систем.
ВВС США в качестве методологии блочного моделирования выбрали методологию SADT и в рамках программы ICAM разработали методологию IDEF (ICAM Definition), позволяющую проводить исследование определенных характеристик промышленного производства.

Modeling) имеет дело с моделями следующих типов:
IDEF0 -

методология функционального моделирования. С помощью наглядного графического языка IDEF0 система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функциональных блоков. Как правило, моделирование средствами IDEFO является первым этапом изучения любой системы. Эта нотация используется для создания укрупненной модели бизнес-процессов предприятия;
IDEF1 (Data Flow Diagram, DFD) - методология информационного моделирования документооборота внутри системы, позволяющая отображать и анализировать структуру информационных потоков и их взаимосвязи. DFD диаграмма или диаграмма потоков данных - используется на этапе исследования предметной области (при концептуальном моделировании) для описания документооборота и обработки информации как дополнение к модели IDEF0. DFD описывают работы, документы (обозначаются стрелками - arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации (внешние ссылки - external references) и таблицы для хранения документов (хранилище данных - data store). В отличие от IDEF0 для стрелок нет понятия вход, выход, управление или механизм, и неважно, в какую грань работы входит или из какой грани выходят стрелки.

относится к типу методологий СУЩНОСТЬ - СВЯЗЬ (ER, Entity Relationship),

применяется для построения логических моделей реляционных БД;
IDEF3 (WorkFlow, WFD) - методология уточнения технологии выполнения работ на предприятии, технологии обработки информации. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса, сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время. WFD диаграмма используется для графического описания связей между процессами обработки информации и объектами, являющимися частью этих процессов, и информационных потоков. IDEF3 имеет прямую взаимосвязь с методологией IDEF0: каждый функциональный блок может быть представлена в виде отдельного процесса средствами IDEF3, т.е. нотация IDEF3 используется для детализации модели, созданной с помощью нотации IDEF0.

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

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

выполнять данную функцию

из 3, но не более чем из 6 прямоугольников. Верхний

предел (6) заставляет использовать иерархии при описании сложных предметов. Нижний предел (3) гарантирует, что на диаграмме достаточно деталей, чтобы оправдать проведение декомпозиции (детализации). Достоинство методологии IDEF0 состоит в том, что она впервые позволяет получить четкое представление о том, что на самом деле происходит в компании (модель «AS IS»), а также то, что должно происходить для наиболее эффективного функционирования компании (модель «TO BE»).

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

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

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

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

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

стрелка выхода вышестоящей работы (далее — просто выход)

Связь по управлению

(output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов


Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса


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

диаграмм потоков данных (DFD, стандарт IDEF1), описывающих процесс преобразования информации

от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней (контекстные) определяют основные процессы или подсистемы ИС с внешними входами и выходами Компоненты диаграмм DFD:
внешние сущности (заказчики, персонал, поставщики, клиенты, склад);
системы/подсистемы, процессы;
накопители данных;
потоки данных.
Внешние сущности порождают потоки, переносящие информацию к подсистемам или процессам, накопителям данных или внешним сущностям - потребителям информации

1. Внешняя сущность обозначается квадратом с тенью

Процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2,

12.3.
Пример имени процесса:
Ввести сведения о клиентах;
Выдать информацию о расходах;
Проверить данные клиента.

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

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

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

с приемниками и источниками информации. Для сложных ИС строится иерархия контекстных диаграмм.
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. При детализации должны выполняться следующие правила:
правило балансировки - детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет связь детализируемая подсистема или процесс на родительской диаграмме;
правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
возможности описания преобразования данных процессом в виде последовательного алгоритма;
выполнения процессом единственной логической функции преобразования входной информации в выходную;
возможности описания логики процесса при помощи мини-спецификации небольшого объема (не более 20-30 строк).

IDEF3
Диаграмма описания последовательности этапов процесса (Process Flow Description Diagrams, PFDD)
Диаграмма

состояний объекта и его трансформаций в процессе (Object State Transition Network, OSTN)

"сущность-связь" (Entity-Relationship или ER-модель), которая в настоящее время стала основой

методологии концептуального проектирования БД и методологии логического проектирования реляционных БД.
Известны также нотации Баркера (Barker) и IE (Information Engineering)

Нотация Баркера имеет отличительную особенность в виде оперения на одном из концов линии, связывающей объекты. Этот знак называют “воронья (гусиная) лапка” и он соответствует отношению “ко многим” между объектами
Обозначения, применяемые в диаграмме Баркера: “#” – первичный ключ или чисть первичного ключа, “*” – заполнение атрибута обязательно, “°” - атрибут дополнительный, т.е. заполнение атрибута не обязательно. Связь между таблицами-объектами может быть изображена в виде сложенной из двух отрезков линии. Если часть отрезка сплошная, то связь одной таблицы с другой (роль одного объекта по отношению к другому) - обязательная.

обязательно, например, отдел может не иметь на одного сотрудника, “|”

– заполнение атрибута обязательно, “O|” – атрибут принимает самое большее одно значение (т.е. ни одного значения или одно значение), “||” - атрибут принимает только одно значение.

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

Обозначения применяемые в диаграммах на языке relational для типов значений в столбцах таблиц: PK (Primary Key) – первичный ключ, FK (Foreign Key) – внешний ключ, AK (Alternate Keys) – вторичный ключ, U (Unique) – уникальные значения, I (Index) - индекс.

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

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

по торговле автомобилями. Исходная информация:
цена и накладные расходы.
кто

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

Связь (Relationship) - поименованная ассоциация между двумя сущностями.

Связь продавца с контрактом :
продавец может получить вознаграждение за 1 или более контрактов;
контракт должен быть инициирован ровно одним продавцом.

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

"#" ).

Атрибут - характеристика сущности. Атрибут может быть либо обязательным (IS NOT NULL), либо необязательным.

Дополним построенную ранее диаграмму

БД создаются с использованием нотации relational нотации ER. Логическая модель

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

“много”

“один”

“необязательная”

Связи:

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

SQL Server.

Нотация языка ER для отображения схемы данных в СУБД MS Access. В отличие от MS Visio видно - по каким полям связаны таблицы

позволяет построить модель данных, эквивалентную РМД в 3-ей нормальной форме.
Сущность

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

с помощью CASE средств: Oracle Designer (Oracle), PowerDesinger (Sybase), AllFusion

Data Modeler или ERwin (Computer Associates), AllFusion Process Modeler или BPWin (Computer Associates), Visio Enterprise Edition (MS). ERWin и BPWin – разработки компании Logic Works, затем права принадлежали PLATINUM technologies, теперь принадлежат компании Computer Associates.
В BPWin из состава DFD-диаграмм программно выделяются внешние сущности (хранилища данных) и переносятся на ER-диаграмму (ER – Entity Relationship, сущность-связь ). При этом сохраняется наиболее распространенная в рамках DFD моделей нотация IDEF1X описания РБД. Анализируются функции и определяются связи между сущностями предметной области. Определяются ключевые атрибуты и состав неключевых атрибутов сущностей.
В MS Visio для создания концептуальной модели, программно преобразуемой в логическую модель, используется язык ORM (Object-Role Modeling). Использование MS Visio позволяет на всех этапах моделирования выполнить проверку корректности моделей, выявить несоответствие типов данных и внести в их описание изменения до генерации физической модели.

(Falkenberg). В Европе метод известен как NIAM (Natural language Information

Analysis Method). Данный язык также имеет нотации ORM2, MOON (Normalized Object-Oriented Method), PSM (Predicator Set Model), NORM (Natural Object-Relationship Model), FORM (Formal ORM), FCO-NIAM (Fully Communication Oriented NIAM). Система OSA (Object-oriented Systems Analysis) включает упрощенный ORM-компонент.
Объектно-ролевое моделирование ORM использует набор типовых отношений между объектами. Несмотря на то, что данный язык моделирования не получил широкого распространения, он позиционируется компанией MicroSoft в лице Тэрри Халпина (Terry Halpin) как наиболее приемлемый для общения специалиста предметной области и разработчика ИС благодаря тому, что ограниченное количество вариантов отношений между объектами позволяет формализовать их описание почти на разговорном языке.

Для установления типа отношения между объектами служит роль, например, учится

(“Студент учится в вузе”) и/или учатся (“В вузе учатся студенты”). Большинство отношений между объектами – бинарные. Унарное отношение - Студент женат. Пример ORM-диаграммы для фактов “у человека есть телефон”, “человек живет по определенному адресу”, “человек родился в определенный день”, “человек был принят на работу в определенный день”:

Стрелка на изображении факта “у человека есть телефон” - “возможно, что у одного человека есть более одного телефона и что у более, чем одного человека, есть один и тот же телефон (например, в организации)”.
Для факта “человек родился в определенный день” комбинация стрелки и точки означает, что каждый человек родился в один и только один конкретный день.
Если линия вокруг объекта пунктирная, то значение объекта не уникальное.