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

Проектирование баз данных Процесс типового проектирования БД включает в себя: 1. построение концептуальной (инфологической) модели предметной области (по результатам предпроектного обследования); 2. выбор типа БД и проектирование логической (даталогической) модели БД; 3. выбор СУБД и проектирование физической модели БД; 4. разработку программных модулей и процедур для работы с приложением БД; 5. разработку процедур для администрирования БД.

ЭТАПЫ проектирования БД Предметная область 1. Анализ предметной области Концептуальная модель данных 2. Выбор модели представления данных Логическая модель данных Физическая модель данных 4. Генерация БД BPWin, ERWin, MS Visio 3. Выбор СУБД Манипулирование данными Описание данных СУБД База данных 5. Создание приложений Приложение 1 Приложение 2 Приложение 3 CASE средства

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

Отражение бизнес- процессов компании на модели … данные, собранные на предпроектном обследовании предмета автоматизации (должностные инструкции, положения о подразделениях, описание входных и выходных форм, анкеты, опросы, приказы, руководства) Отображаются в моделях…

Типы моделей Функциональные- IDEF0 Потоков данных- IDEF1 (DFD) Процессов- IDEF3 (WorkFlow) Логические- IDEF1X (ER) Комплексные- ARIS (стандарт де-факто, признан среди разработчиков и пользователей), 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.

IDEF0DFD (IDEF1) WorkFlow (IDEF3) ER (IDEF1X)

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

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

IDEF1X (ER) - методология построения реляционных структур. IDEF1X относится к типу методологий СУЩНОСТЬ - СВЯЗЬ (ER, Entity Relationship), применяется для построения логических моделей реляционных БД; IDEF3 (WorkFlow, WFD) - методология уточнения технологии выполнения работ на предприятии, технологии обработки информации. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса, сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время. WFD диаграмма используется для графического описания связей между процессами обработки информации и объектами, являющимися частью этих процессов, и информационных потоков. IDEF3 имеет прямую взаимосвязь с методологией IDEF0: каждый функциональный блок может быть представлена в виде отдельного процесса средствами IDEF3, т.е. нотация IDEF3 используется для детализации модели, созданной с помощью нотации IDEF0. В результате дополнения диаграмм IDEF0 диаграммами DFD и WFD может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия.

Контекстная диаграмма IDEF0

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

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

Типы связей в диаграмме IDEF0

5 типов связей работ в IDEF0 Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее просто выход) Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса Связь выход-механизм (output-mechanism) - выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы

Необходимость туннелирования потоков

Диаграмма дерева узлов модели

Нотации языка ER В 1976 году Чен (Peter Chen), предложил модель "сущность-связь" (Entity- Relationship или ER-модель), которая в настоящее время стала основой методологии концептуального проектирования БД и методологии логического проектирования реляционных БД. Известны также нотации Баркера (Barker) и IE (Information Engineering) Нотация Баркера имеет отличительную особенность в виде оперения на одном из концов линии, связывающей объекты. Этот знак называют воронья (гусиная) лапка и он соответствует отношению ко многим между объектами Обозначения, применяемые в диаграмме Баркера: # – первичный ключ или чисть первичного ключа, * – заполнение атрибута обязательно, ° - атрибут дополнительный, т.е. заполнение атрибута не обязательно. Связь между таблицами-объектами может быть изображена в виде сложенной из двух отрезков линии. Если часть отрезка сплошная, то связь одной таблицы с другой (роль одного объекта по отношению к другому) - обязательная.

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

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

Вид в MS Visio модели в нотации реляционного (relational) моделирования языка ER. Эта же нотация используется в диаграммах БД MS SQL Server. Нотация языка ER для отображения схемы данных в СУБД MS Access. В отличие от MS Visio видно - по каким полям связаны таблицы

ER диаграмма (логическая модель БД) в MS Visio

Преобразование концептуальной модели в логическую 1. Создать логическую или концептуальную модель можно с помощью 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. 2. В BPWin из состава DFD-диаграмм программно выделяются внешние сущности (хранилища данных) и переносятся на ER-диаграмму (ER – Entity Relationship, сущность-связь ). При этом сохраняется наиболее распространенная в рамках DFD моделей нотация IDEF1X описания РБД. Анализируются функции и определяются связи между сущностями предметной области. Определяются ключевые атрибуты и состав неключевых атрибутов сущностей. 3. В MS Visio для создания концептуальной модели, программно преобразуемой в логическую модель, используется язык ORM (Object-Role Modeling). Использование MS Visio позволяет на всех этапах моделирования выполнить проверку корректности моделей, выявить несоответствие типов данных и внести в их описание изменения до генерации физической модели.

Язык ORM (Object-Role Modeling, моделирование ролей объектов) назван так Фалкенбергом (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 представляет бизнес-процесс как факт с различными типами объектов. Для установления типа отношения между объектами служит роль, например, учится (Студент учится в вузе) и/или учатся (В вузе учатся студенты). Большинство отношений между объектами – бинарные. Унарное отношение - Студент женат. Пример ORM-диаграммы для фактов у человека есть телефон, человек живет по определенному адресу, человек родился в определенный день, человек был принят на работу в определенный день: Стрелка на изображении факта у человека есть телефон - возможно, что у одного человека есть более одного телефона и что у более, чем одного человека, есть один и тот же телефон (например, в организации). Для факта человек родился в определенный день комбинация стрелки и точки означает, что каждый человек родился в один и только один конкретный день. Если линия вокруг объекта пунктирная, то значение объекта не уникальное.

Пример ORM модели

Соответствующая логическая модель (Visio)

Соответствующая логическая модель (Access)