Содержание

CASE-средства проектирования баз данных

CASE-средства (Computer — Aided Software Engineering) — это методы и технологии, которые позволяют проектировать различные информационные системы (в частности, базы данных) и автоматизировать их создание. О проектировании баз данных, видах CASE-средств и об особенностях их применения будет рассказано в представленной статье.

Проектирование баз данных с помощью CASE-средств

К ключевым понятиям проектирования баз данных относятся:

  • CASE-технологии — программная основа CASE-средств, применяемая для разработки и поддержки процессов жизненных циклов ПО, используемых в моделировании данных и генерации схем баз данных. Чаще всего программные коды в CASE-технологиях пишутся на языке SQL;
  • концептуальное проектирование — построение обобщенной, не имеющей конкретики, модели базы данных с описанием ее объектов и связей между ними;
  • логическое проектирование — создание схемы базы данных с учетом специфики конкретной модели данных (но не конкретной СУБД).
    Например, для реляционной модели данных логическая схема БД будет содержать определенный набор таблиц и связей между ними;
  • физическое проектирование — построение схемы базы данных под конкретную СУБД. При таком проектировании учитываются ограничения на именование объектов базы данных, ограничения на определенные типы данных, физические условия хранения данных в БД (разделение по файлам и устройствам), возможность доступа к БД.

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

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

  • ERwin (Logic Works) — CASE-инструмент для создания концептуальных и логических схем баз данных. Он позволяет редактировать различные наборы данных, представляя их в виде электронных таблиц, разрабатывать структуры баз данных, синхронизировать модели, скрипты и БД, настраивать шаблоны, выводить рабочую информацию в виде отчетов, строить удобные и понятные диаграммы, отображающие различные процессы в системе и взаимосвязи между ними;
  • S-Designor (SDP) — графический CASE-инструмент для проектирования структуры реляционных БД. Он создает модели баз данных в два этапа — выстраивая концептуальную модель и затем преобразуя ее в физическую, причем в данном процессе разработки возможен как прямой, так и обратный переход между моделями. Данный инструмент позволяет проектировать базы данных под различные СУБД, в том числе под Oracle и MySQL;
  • DataBase Designer (ORACLE) — интегрированная CASE-среда, которая позволяет анализировать предметную область создания БД, выполнять программирование и проектирование, проводить оценку и тестирование, осуществлять сопровождение, обеспечивать качество, управлять конфигурацией и проектом, разрабатывать и анализировать требования к информационной системе.

Классификация CASE-средств

В зависимости от того, на каком этапе проектирования баз данных используются CASE-средства, их относят к:

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

Обучение проектированию баз данных с помощью CASE-средств доступно для всех желающих в рамках профессиональной подготовки по «Инструментальные средства бизнес-аналитики», которую проводит ВШБИ НИУ ВШЭ.

Записаться на обучение по данному курсу можно на нашем сайте.


← Назад к списку

Основы проектирования баз данных — Учебная и научная деятельность Анисимова Владимира Викторовича

Проектирование информационных систем

Лекции

Тема 7. Разработка информационной модели

7.1. Основы проектирования баз данных

 

Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе.

В то же время она не отвечает на вопрос «Каким образом организованы данные в системе?». Для ответа на него необходимо построить информационную модель (запроектировать БД).

Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием соответствующей информационной модели [1, 21].

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

Этап 2-й. Логическое проектирование – развитие концептуальной схемы БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.).

Этап 3-й. Физическое проектирование – развитие логической схемы БД с учетом выбранной целевой СУБД.

Концептуальное и логическое проектирование вместе называют также инфологическим или семантическим проектированием.

В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование

ERD (Entity – Relationship Diagrams, диаграммы «сущность–связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования.

ERD были впервые предложены П. Ченом в 1976 г. Основные элементы ERD перечислены ниже [21].

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

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

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

Атрибут (столбец, поле) – свойство сущности или связи.

Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: IDEF1X и IE (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т.е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели.

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

Логической схемой называется универсальное описание структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании полученной логической схемы переходят к физической схеме данных. Физическая схема представляет собой диаграмму, содержащую всю необходимую информацию для генерации БД для конкретной СУБД или даже конкретной версии СУБД. Если в логической схеме не имеет значения, какие идентификаторы носят таблицы и атрибуты, тип данных атрибутов и т. д., то в физической схеме должно быть полное описание БД в соответствии с принятым в ней синтаксисом, с указанием типов атрибутов, триггеров, хранимых процедур и т.д. По одной и той же логической схеме можно создать несколько физических. Например, ERwin v9.2 позволяет на основании логической схемы сформировать физические более, чем для 10 промышленных СУБД (ORACLE, MySQL, DB2, MS SQL Server и др.) и их различный версий. На основании физической схемы можно сгенерировать либо саму БД или DDL-скрипт
1, который, в свою очередь, может быть использован для генерации БД.

Перечисленный выше порядок действий называется прямое проектирование БД (Forward Engineering DB). CASE-средства позволяют выполнять также обратное проектирование БД (Reverse Engineering DB), т.е. на основании системного каталога БД или DDL-скрипта построить физическую и, далее, логическую схему данных.

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

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

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

Далее рассматривается процедура прямого проектирования с использованием методологии IDEF1X. Методология IDEF1 была разработана Р. Брауном и Т. Рэмеем из Hughes Aircraft и Д. Коулмэном из DACOM. Также, как и IDEF0, IDEF1 была признана полезной в рамках программы ICAM и в 1981г. принята в качестве федерального стандарта США. В 1985г. методология была расширена и получила название IDEF1X (X — eXtended). Последняя редакция стандарта (FIPS Pub 184 «Integration definition for information modeling (IDEF1X)» [48]) была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (NIST) и отозвана в 2008г. В настоящее время действующим является международный стандарт на информационное моделирование посредством IDEF1X (ISO/IEC/IEEE 31320-2-2012 «Information technology — Modeling Languages — Part 2: Syntax and Semantics for IDEF1X97 (IDEFobject)» [49]).

1Data Definition Language – язык определения данных, подмножество языка SQL.

Автоматизация проектирования баз данных | Наука

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

Современные CASE-средства позволяют создавать синтаксические модели базы данных на этапах 4 и 5, исходя из инфологической модели предметной области, построенной человеком (проектировщиком БД) на этапе 2. Очевидно, что этапы 1 и 3 полностью не формализуются. Этап 2 допускает лишь частичную автоматизацию, поскольку только человек способен построить в своей голове инфологическую модель предметной области, а лишь потом для описания этой модели применить соответствующие CASE-средства.

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

Современная CASE-индустрия объединяет сотни известных фирм и компаний. В настоящее время практически все серьезные проекты осуществляются с использованием CASE-средств. Общее число распространяемых на рынке программных продуктов CASE-средств составляет порядка 500 наименований. По ориентации на этапы проектирования выделяют следующие типы CASE-средств: инструменты анализа и моделирования предметной области; средства проектирования баз данных; средства разработки приложений. По степени независимости от СУБД различают независимые и встроенные CASE-средства.

После построения проекта БД начинается процесс реализации этого проекта, т. е. создание БД. Создание БД и дальнейшая ее эксплуатация традиционно осуществляется с помощью специальных программного обеспечения которое называют по-разному: диспетчер базы данных (database manager), сервер базы данных (database server) или, что более привычно, система управления базами данных, СУБД (DataBase Management System — DBMS).

Средства автоматизации проектирования базы данных. Основные определения

Средства автоматизации проектирования базы данных

Определение 1

Системой автоматизированного проектирования (САПР) называют организационно-техническую систему, состоящую из комплекса средств автоматизации проектирования, который взаимодействует с подразделениями проектной организации, и выполняющую автоматизированное проектирование.

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

Определение 2

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

Техническое обеспечение делится на следующие группы:

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

Определение 3

К математическому обеспечению САПР относятся алгоритмы и методы выполнения проектных процедур, математические модели объектов, которые используются при автоматизированном проектировании.

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

Определение 4

К программному обеспечению (ПО) САПР относятся сами программы для систем обработки данных на машинных носителях и программная документация, необходимая для эксплуатации данных программ.

ПО делится на прикладное (или специальное), базовое и общесистемное. Общесистемное ПО представлено операционными системами компьютера и предназначается для организации работы технических средств. Таким образом, специфика САПР общесистемным ПО не отражается. Прикладное и базовое ПО создается для обеспечения САПР. К базовому ПО относятся программы, которые обеспечивают правильную работу прикладных программ.

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

Основной составной частью информационного обеспечения САПР является банк данных, который представляет собой совокупность средств для коллективного использования и централизованного накопления данных в САПР. Банк данных включает базу данных и систему управления базой данных.

Определение 6

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

Определение 7

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

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

Определение 8

Лингвистическое обеспечение САПР представляет собой совокупность языков, которые применяются для описания проектных решений и процедур автоматизированного проектирования.

Определение 9

К методическому обеспечению САПР относятся документы, которые характеризуют правила эксплуатации и отбора, состав средств автоматизированного проектирования.

Определение 10

К организационному обеспечению САПР относят квалификационные требования, приказы, инструкции, положения и другие документы.

Проектирование БД | ЛЕКЦИИ | Bd-Subd.Ru

ЛЕКЦИИ

Лекция 

Проектирование БД.

Модели многоуровневой архитектуры систем баз данных. Средства автоматизации проектирования

 

1. Модели многоуровневой архитектуры систем баз данных

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

Опубликованный в 1975 году отчет ANSI/X3/SPARC зафиксировал не только широкое признание концепций многоуровневой архитектуры систем баз данных, но и необходимость явного выделения специального концептуального уровня представления базы данных, единого для всех ее приложений и независимого от них. Кроме этого уровня предусматривались еще два уровня: внутренний уровень, который должен обеспечивать поддержку представления хранимой базы данных, и внешний, поддерживающий представления базы данных “с точки зрения” приложений. На каждом архитектурном уровне предполагалось использование той или иной модели данных. Кроме того, на внешнем (прикладном, пользовательском) уровне таких моделей может быть несколько. Модели, а также схемы, специфицируемые на их основе, называются, соответственно, внешней, концептуальной и внутренней.

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

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

 

7.2. Типология моделей

Основные отличия любых методов представления информации заключаются в том, каким способом фиксируется семантика предметной области. Но, следует особо отметить, что для всех уровней и для любого метода представления предметной области (но для нас важно, что в контексте создания и использования машинных баз данных) в основе отображения (т. е., собственно формирования представления) лежит кодирование понятий и отношений между понятиями. Многоуровневая система моделей представления информации иллюстрируется слайдами 2, 3, 4 (Типология моделей).

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

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

Однако в большинстве систем, если говорить, например, о базах данных, типы данных являются более статичным элементом, чем способы их обработки. Поэтому получили интенсивное развитие такие методы системного анализа, как диаграммы массивов данных (Data Flow Diagram). Развитие реляционных баз данных в свою очередь стимулировало развитие методик построения моделей данных, и в частности, ER-диаграмм (Entity Relationship Diagram). Но и функциональная декомпозиция и диаграммы данных дают только некоторый срез исследуемой предметной области, но не позволяют получить представление системы в целом.

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

 

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

Представление схем БД в виде схем отношений упрощает процедуру проектирования БД. Этим объясняется создание систем, в которых проектирование БД ведется в терминах реляционной модели данных, а работа с БД поддерживается СУБД одного из описанных в данном пособии типов.

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

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

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

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

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

 

7.3. Этапы проектирования и объекты моделирования

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

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

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

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

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

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

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

Представленная трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. Хранимые данные могут быть переписаны на другие носители или может быть реорганизована их физическая структура, в том числе дополнена полями для новых приложений, но это повлечет лишь изменение физической и, возможно, даталогической модели данных. Главное, такие изменения физической и даталогической моделей не будут замечены пользователями системы (окажутся «прозрачными» для них). Кроме того, независимость данных обеспечивает возможность создания новых приложений для решения новых задач без разрушения существующих.

 

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

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

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

 

7.4. Подходы к проектированию базы данных

Можно выделить два основных подхода к проектированию баз данных: нисходящий и восходящий (слайд 7)

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

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

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

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

—       реляционная модель не предоставляет достаточных средств для фиксации смысла данных, т. е. семантика предметной области не фиксируется непосредственно в отношениях;

—       для многих приложений трудно моделировать предметную область на основе плоских таблиц;

—       хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не имеет средств представления (отражения семантики) этих зависимостей;

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

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

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

 

7.5. Инфологические модели (системный анализ) предметной области

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

Главная идея процесса такого согласования состоит в том, что его надо начинать с анализа самых главных характеристик предметной области, рассматривая самые главные содержательные аспекты. И проводить его не «мысленно» и не «на словах», а на явно изложенных описаниях (моделях) объектов предметной области, позволяющих видеть все существенные взаимосвязи. Но следует отметить, что попытки использования привычных нотаций формальных моделей (структурных, объектных или каких либо других) на этом этапе приводят к более низкому (более детальному и в тоже время ограниченному) уровню представления предметной области, чем это необходимо для общего понимания.

В общем случае существуют два подхода к определению состава и структуры предметной области.   (Слайд 9 Функциональный – объектный подходы)

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

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

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

Цель системного анализа предметной области как этапа проектирования – выделить предметную область как систему объектов и их взаимосвязей, определив при этом функционально-информационные требования к их последующему представлению в виде системы взаимосвязанных данных.

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

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

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

7.6. Даталогические модели

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

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

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

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

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

 

7.7. Физические модели

Стадия физического проектирования базы данных в общем случае включает:

—       выбор способа организации базы данных;

—       разработку спецификации внутренней схемы средствами модели данных ее внутреннего уровня;

—       описание отображения концептуальной схемы во внутреннюю.

Важно заметить, что в отличие от ранних СУБД, многие современные системы не предоставляют разработчику какого-либо выбора на этой стадии. Реально к вопросам проектирования физической модели можно отнести выбор схемы размещения данных (разделение по файлам или тип RAID-массива) и определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server).  

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

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

 

7.8. Средства автоматизации проектирования

Формализованные знания о предметной области в общем случае могут быть представлены в виде текстовых описаний: наборов должностных инструкций, правил ведения дел и т.п. Однако текстовый способ представления модели предметной области не эффективен. Более информативным и полезным при разработке баз данных и информационных систем являются описания предметной области, выполненные при помощи специализированных графических нотаций, реализующих методики представления знаний о предметной области. Наиболее известными на сегодняшний день являются методика структурного анализа SADT (Structured Analysis and Design Technique) и основанная на ней нотация IDEF0, диаграммы массивов данных, методика объектно-ориентированного анализа UML (Unified Modeling Language) и др. Любая из этих моделей описывает, с одной стороны, процессы, происходящие в предметной области, а с другой – данные, используемые этими процессами.

Наиболее полная система моделей, на которую опираются методики функционального, информационного и поведенческого моделирования ПрО, представлена в семействе стандартов IDEF (Integrated DEFinition)     (слайд 10).

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

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

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

CASE-средства в соответствии с их функциональной ориентацией на те или иные процессы жизненного цикла ИС можно подразделить на следующие группы (слайд 11 – САSE).

 

 

CASE-средства проектирования баз данных

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

Проектирование баз данных с помощью CASE-средств

Ключевыми понятиями проектирования базовых данных:

  • CASE-технологии — программная основа CASE-средства, применяемая для разработки и поддержки процессов жизненных циклов ПО, используются в моделировании данных и генерации баз данных.Чаще всего программные коды в CASE-технологии пишутся на языке SQL;
  • концептуальное проектирование — построенная обобщенная, не имеющая конкретики, модели базы данных с описанием ее объектов и связей между;
  • логическое проектирование — создание схемы базы данных с учетом специфики конкретной модели модели данных (но не конкрет СУБД). Например, для реляционной модели данных логическая схема БД будет содержать набор таблиц и связей между ними;
  • физическое проектирование — построение схемы базы данных под конкретную СУБД. При таком проектировании учитываются ограничения на именование объектов базы данных, ограничения на физические, физические условия хранения данных в БД (раздел по файлам и устройствам), возможность доступа к БД.

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

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

  • ERwin (Logic Works) — КЕЙС-инструмент для создания концептуальных и логических баз данных. Он позволяет редактировать различные наборы данных, представлять их в виде электронных таблиц, разрабатывать структуры баз данных, синхронизировать модели, скрипты и БД, настраивать шаблоны, выводить рабочую информацию в виде отчетов, строить удобные и понятные диаграммы, отображать различные в системе и взаимосвязи между им;
  • S-Designor (SDP) — графический CASE-инструмент для проектирования структур реляционных БД. Он создает модели базовых данных в два этапа — выстраивая концептуальную модель и затем преобразуя ее в физическую, причем в данном процессе разработки возможен прямой, так и обратный переход между моделями. Данный инструмент позволяет проектировать базы данных под различные СУБД, в том числе под Oracle и MySQL;
  • Дизайнер баз данных (ORACLE) — интегрированная CASE-среда, которая позволяет анализировать предметную область создания БД, выполнять программирование и проектирование, проводить оценку и выполнение, осуществлять сопровождение, обеспечивать качество, управлять конфигурацией и проектом, разрабатывать и анализировать требования к информационная система.

Классификация CASE-средств

В зависимости от того, на каком этапе проектирования баз данных используются CASE-средства, относят к:

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

Обучение проектированию базовых данных с помощью CASE-средств доступно для всех желающих в рамках подготовки по «Инструментальные средства бизнес-аналитики», которую проводит ВШБИ НИУ ВШЭ.Записаться на обучение по данному курсу можно на нашем сайте.


← Назад к списку

Основы проектирования баз данных — Учебная и научная деятельность Анисимова Владимира Викторовича

Проектирование информационных систем

Лекции

Тема 7. Разработка информационных моделей

7.1. Основы проектирования баз данных

Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе.

В то же время она не отвечает на вопрос «Каким образом организованы данные в системе?». Для ответа на него необходимо построить информационную модель (запроектировать БД).

Традиционно компьютерное проектирование базы данных разбивается на три этапа, каждый из которых запускается через систему информационных моделей [1, 21].

Этап 1-й. Концептуальное проектирование — создание схемы БД, включающего определение важнейших сущностей (таблиц) и связей между ними, но не зависящего от модели БД (иерархической, сетевой, реляционной и т.д.) и реализации (задача СУБД).

Этап 2-й. Логическое проектирование — развитие концептуальной схемы БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.).

Этап 3-й. Физическое проектирование — разработка логической схемы БД с учетом выбранной СУБД.

Концептуальное и логическое проектирование вместе называют также инфологическим или семантическим проектированием .

В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование ERD (Entity — Relationship Diagrams, диаграммы «сущность – связь») . С помощью их важных элементов для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что существует необходимость проектирования ERD в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-используемой, то лучше избрать другие методы проектирования.

ERD были впервые предложены П. Ченом в 1976 г. Основные элементы ERD ниже [21].

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

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

Связь — некоторая ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Примерами связей могут являться родственные отношения «отец – сын», производственные — «начальник-подчиненный» или произвольные — «иметь в собственности», «обладать своимством».

Атрибут (столбец, поле) — свойство сущности или связи.

Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций информационных моделей.В частности система ERwin фирмы Computer Associates поддерживает нотации: IDEF1X и IE (англ. Информационная инженерия — информационное проектирование). Данные нотации являются взаимно-однозначными, т.е. переход от одной нотации к другому и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели.

При использовании любого CASE-средства вначале строится логическая схема БД в виде диаграммы с указанием сущностей и связей между. Логической схемой называется универсальное описание структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании логической схемы переходят к полученной схеме данных. Физическая схема представляет собой диаграмму, содержащую всю специальную информацию для информации СУБД или даже конкретную СУБД. Если в логической схеме не имеет значения, какие индикаторы носят таблицы и атрибуты, тип данных атрибутов и т.д., то в физической схеме должно быть полное описание БД в соответствии с принятым в ней синтаксисом, с указанием типов типов, триггеров, хранимых процедур и т.д. По одной и той же логической схеме можно создать несколько физических. Например, ERwin v9.2 позволяет на основании логической схемы сформировать более, чем для 10 промышленных СУБД (ORACLE, MySQL, DB2, MS SQL Server и др. ) И их различные версии. На основании физических схем можно сгенерировать либо саму БД или DDL-скрипт 1 , который, в свою очередь, может быть использован для генерации БД.

Перечисленный выше порядок действий называется прямое проектирование БД . CASE-средства позволяют выполнять также обратное проектирование БД (Reverse Engineering DB) , т.е. на основании системного каталога БД или DDL-скрипта построить физическую и далее, логическую схему данных.

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

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

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

Далее процедура прямого проектирования с использованием методологии IDEF1X . Методология IDEF1 была предоставлена ​​Р.Брауном и Т. Рэмеем из Hughes Aircraft и Д. Коулмэном из DACOM. Также, как и IDEF0, IDEF1 была признана полезной в рамках программы ICAM и в 1981г. принята в качестве в федерального стандарта США. В 1985г. методология была расширена и получила название IDEF1X (X — eXtended). Последняя редакция стандарта (FIPS Pub 184 «Определение интеграции для информационного моделирования (IDEF1X)» [48]) была выпущена в декабре 1993г. Национальный институт по стандартам и технологиям США (NIST) и отозвана в 2008г. В настоящее время действующим является международный стандарт на информационное моделирование посредством IDEF1X (ISO / IEC / IEEE 31320-2-2012 «Информационные технологии — Языки моделирования — Часть 2: Синтаксис и семантика для IDEF1X 97 (объект IDEF )» [49 ]).

1 Язык определения данных — язык определения данных, подмножество языка SQL.

Автоматизация проектирования баз данных | Наука

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

Современный CASE -средства позволяют создавать синтаксические модели базы данных на этапах 4 и 5, исходя из инфологической модели предметной области, построенной человеком (проектировщиком БД) на этапе 2. Очевидно, что этапы 1 и 3 полностью не формализуются. Этап 2 допускает лишь частичную автоматизацию, поскольку только человек способен построить в своей голове инфологическую модель предметной области, а потом для этой модели применяются соответствующие CASE -средства.

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

Современная CASE -индустрия объединяет сотни известных фирм и компаний. В настоящее время практически все серьезные проекты осуществляются с использованием CASE -средств. Общее число распространяемых на рынке программных продуктов ДЕЛО -средств составляет порядка 500 наименований. По ориентации на этапы проектирования выделяют следующие типы CASE -средств: инструменты анализа и моделирования предметной области; средства проектирования баз данных; средства разработки приложений.По степени независимости от СУБД различают независимые и встроенные CASE -средства.

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

Средства автоматизации проектирования базы данных. Основные определения

Средства автоматизации проектирования базы данных

Определение 1

Системой автоматизированного проектирования (САПР) называют организационно-техническую систему, состоящую из комплекса средств проектирования, который отвечает с подразделениями проектной организации, и выполняющую автоматизированное проектирование.

Средства проектирования могут быть сгруппированы по видам обеспечения данного процесса.

Определение 2

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

Техническое обеспечение делится на следующие группы :

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

Определение 3

К математическому обеспечению САПР алгоритмы и методы выполнения проектных, процедурных моделей объектов, которые используются при автоматизированном проектировании.

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

Определение 4

К программному обеспечению (ПО) САПР сами программы для систем обработки данных на машинных носителях и программная документация, необходимая для эксплуатации данных программ.

ПО делится на прикладное (или специальное), базовое и общесистемное . Общесистемное ПО представляет собой операционные системы компьютера и предназначается для организации работы технических средств. Таким образом, специфика САПР общесистемным ПО не отражается. Прикладное и базовое ПО создается для обеспечения САПР. К базовому ПО ракетной программы, обеспечивающей правильную работу прикладных программ.

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

Основная составная часть информационного обеспечения САПР представляет собой банк данных , представляющую собой совокупность средств для коллективного использования и централизованного накопления данных в САПР. Банк данных включает базу данных и систему управления базой данных .

Определение 6

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

Определение 7

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

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

Определение 8

Лингвистическое обеспечение САПР представляет собой совокупность языков, которые применяются для описания проектных решений и процедурного проектирования.

Определение 9

К методическому обеспечению САПР относятся документы, которые характеризуют правила эксплуатации и отбора, состав средств автоматизированного проектирования.

Определение 10

К организационному обеспечению САПР квалификационные требования, приказы, инструкции, положения и документы.

.

No related posts.