Автоматизированные средства проектирования баз данных Обзор и классификация Case-технологий


Проект студента группы

С-1

Й Курс

Исполнитель

Вельхиев Асланбек Хизирович

Преподаватель Тангиев И.М.

Год.

 

 

1. Введение……………………………………………………………….3

Глава 1. Теоретическая часть

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

Модели баз данных

Иерархическая

Сетевая

Реляционная

Анализ предметной области

Автоматизированные средства проектирования баз данных Обзор и классификация Case-технологий

Глава 2. Практическая часть

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

2.2. Концептуальная модель “Сущность-связь”

Физическая модель базы данных

Хранимые процедуры и триггеры

Заключение

Литература

Приложения

 

 

Введение

 

За последние двадцать лет значительно возрос объём и оборот информации во всех сферах жизнедеятельности человека: экономической, финансовой, политической, духовной. И процесс накопления, обработки и использования знаний постоянно ускоряется. Учёные утверждают, что каждые десять лет количество информации увеличивается вдвое. В связи с этим возникает необходимость использования автоматических средств, позволяющих эффективно хранить, обрабатывать и распределять накопленные данные.

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

Актуальность данного проекта заключается в следующем: во-первых, компьютерный учет имеет свои особенности и радикально отличается от обычного. Компьютер не только облегчает учет, сокращая время, требующееся на оформление документов и обобщение накопленных данных для анализа хода производственной деятельности, необходимого для управления ею. Во-вторых, отчеты о положении в производстве, получаемые с помощью компьютера, можно получить и без него – никакой особой математики в компьютере не содержится – но на расчеты уйдет столько времени, что они уже ни на что не будут нужны; или ими придется занять такое количество расчетчиков, что на их зарплату уйдет значительно больше, чем будет получено прибыли в результате их расчетов.


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

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

Информационная система позволит избавить сотрудника от рутинной

 

 

повседневной работы по выписке расходных накладных. Так как раньше

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

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

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

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

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

 

Глава 1. Теоретическая часть

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

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

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

обработки данных.

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

пользователей.

Свойства БД.: Само документированность. База данных

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

 

Модели баз данных

Иерархическая

Сетевая

Реляционная

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

 

и сотрудников. Другой пример: объект «колесо» является составной частью

объекта «автомобиль». Между автомобилем и колесом имеется связь, смысл

которой можно озвучить следующим образом: объект «автомобиль» включает в

себя несколько объектов «колесо».

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

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

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

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

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

 

(или одну комбинацию полей) можно назначить ключевым. С ключевыми полями

СУБД работает особо. Она проверяет их уникальность и быстрее выполняет

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

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

Анализ предметной области

 

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

· понимать язык, на котором говорят заказчики;

· выявить цели их деятельности;

· определить набор решаемых ими задач;

· определить набор сущностей, с которыми приходится иметь дело при решении этих задач.

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

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

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

Анализ предметной области разбивается на три фазы:

· анализ концептуальных требований и информационных потребностей;

· выявление информационных объектов и связей между ними;

· построение концептуальной модели предметной области и проектирование концептуальной схемы БД.

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

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

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

 

Автоматизированные средства проектирования баз данных Обзор и классификация Case-технологий

 

Проектирования БД является сложным итерационным процессом. Автоматизировать данный процесс можно с помощью современных 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).

 



Рекомендуемые страницы:

Воспользуйтесь поиском по сайту:

megalektsii.ru

Тема 5. Средства автоматизированного проектирования структур баз данных.

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

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

Концептуальное моделирование структуры данных

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

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

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

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

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

Концептуальные модели данных

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

Обычно различают концептуальные модели
двух видов:

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

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

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

Несмотря на то, что в последнее время
все большее распространение получают
объектно-ориентированные модели, не
снижается и значение семантических
моделей. Концептуальное моделирование
баз данных на основе семантических
моделей поддерживается во всех известных
CASE-средствах (например,
таких как ERWin и Power
Designer). Кроме того,
семантические модели более просты для
понимания, особенно при проектировании
сравнительно небольших баз данных.

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

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

Одной из наиболее популярных семантических
моделей данных является модель
«сущность-связь»
(часто называемая
также ER-моделью — по
первым буквам английских слов Entity
(сущность) и Relation (связь)).

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

Для моделирования структуры данных
используются ER-диаграммы
(диаграммы «сущность-связь»), которые
в наглядной форме представляют связи
между сущностями. В соответствии с этим
ER-диаграммы получили
распространение в CASE-системах,
поддерживающих автоматизированное
проектирование реляционных баз данных.
Наиболее распространенными являются
диаграммы, выполненные в соответствии
со стандартом IDEF1X,
который используют наиболее популярные
CASE-системы (в частности,
ERwin, Design/IDEF,
Power Designer).

Основными понятиями ER-диаграммы
являются сущность, связь и атрибут.

studfiles.net

Case технологии в проектировании баз данных

Библиографическая ссылка:

Гайфуллов Р.Р. Case технологии в проектировании баз данных // Портал научно-практических публикаций [Электронный ресурс]. URL: http://portalnp.ru/2014/06/2067 (дата обращения: 08.02.2019)

Гайфуллов Руслан, студент 2 курса, специальность прикладная информатика ФГБОУ ВПО Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «МГТУ имени Носова»

Аннотация

В данной статье дается определение базы данных. Дальше рассматриваются типы данных в базах данных, и их использование при проектировании баз данных. Потом дается определение Case технологий. А в конце, рассказывается о Case технологиях в проектирования баз данных

CASE technologies in database design

Gayfullov Ruslan, 2nd year student, specialty Applied Informatics, FSBEI  HPE “MSTU of a name Nosov” 

Аnnotation

In this article provides a definition database. Further describes the types of data in databases and their use in database design. Then provides a definition database.  And in the end, tells about case technologies in database design.

ЧТО ТАКОЕ БАЗЫ ДАННЫХ

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

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

База данных – множество данных, хранящихся согласно схеме данных, манипуляция с которыми происходит по правилам средств манипулирования данных.

База данных – сведения, хранящиеся неким упорядоченным способом.

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

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

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

Основные задачи:

— Хранение в БД всей нужной информации.

— Возможность получить данные по всем нужным запросам.

— Уменьшение избыточности и дублирования данных.

— Обеспечение целостности и дублирования данных

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

Проектирование БД осуществляется в 3 этапа: концептуальное (инфологическое), логическое (даталогическое), физическое.

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

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

Логическое проектирование – перенесение проекта на внутреннюю модель СУБД (это система управления БД).

Логическое (даталогическое) проектирование – это создание схемы БД с помощью реляционной модели данных.

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

Физическое проектирование – это создание схемы БД для конкретно для нужной системы управления БД (например, Access).

Есть еще один вариант этапов проектирования БД:

1 этап: постановка задачи

2 этап: Анализ предметной области.

3 этап: Создание модели.

4 этап: Выбор способов представления информации и программного инструментария.

5 этап: Создание компьютерной модели объекта.

6 этап: Работа с созданной базой данных.

ЧТО ТАКОЕ CASE ТЕХНОЛОГИИ

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

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

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

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

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

Также подход использует общепринятые методологии, моделируя разные информационные системы, а именно

SADT (Structured Analysis and Design Technique), DFD (Data Flow Diagrams), а также ERD (Entity Relationship Diagrams).

Есть три основные модели в этом подходе:

функциональные, информационные и динамические

Этот подход реализуют Bpwin, Erwin, Business Studio, IBM WebSphere business modeler и Sybase Power Designer.

В объектно-ориентированном подходе основной инструмент – это язык UML – унифицированный язык моделирования, который может визуализировать и документировать объектно-ориентированные системы, ориентированные на разработку ПО. UML имеет систему разных диаграмм для построения представления о проектируемой системе.

Этот подход реализуют Rational Rose и ARIS.

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

Case инструменты делятся на типы и категории:

Типы (здесь отражается функциональная ориентация на разные процессы жизненного цикла разработки ПО и совпадает с составом компонент крупных интегрированных Case систем):

средства анализа, созданные для создания и анализа модели предметной области(Bpwin (logical works).

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

средства проектирования БД, моделирующие данные и генерирующие схемы БД (на SQL) для систем управления базами данных. Это Erwin (Logic works) и DataBase Designer (Oracle) и Designer/2000.

средства разработки приложений (Developer/2000), Delphi).

средства реинжиниринга, анализирующие программные коды и схемы БД, а также формирование с их помощью разных моделей и проектных спецификаций. Средства анализа схем БД и формирование ERD имеют Designer/2000, Erwin. При анализе программных кодов самыми известными являются объектно-ориентированные Case средства, помогающие проводить реинжиниринг программ на языке С++ (Rational Rose).

Вспомогательные типы

средства планирования и управления проектом (Microsoft Project).

средства конфигурационного управления (PVCS (Intersolv)).

средства тестирования (Quality Works (Segue Software)).

средства документирования (SoDA (Rational Software)).

CASE ТЕХНОЛОГИИ В ПРОЕКТИРОВАНИИ БАЗ ДАННЫХ

В качестве Case технологии я рассмотрю Erwin

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

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

Erwin не только инструмент для «рисования», но и автоматизирует проектирование. Ссылочная целостность БД обеспечивается автоматическим переносом ключей. Создающиеся в Erwine модели данных могут редактироваться, просматриваться и распечатываться разными способами. А при помощи RPTwin (имеющей графический интерфейс и умеющей формировать отчеты) и средства для просмотра настраиваемыми режимами, обеспечивающими контроль отображения содержимого отчетов, можно реализовать одинаковые стандарты проектирования и отображения настроек для всех моделей.

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

БД проектируется и создается без написания SQL-предложений. Так как физическая схема формируется на основе описательной логической модели, создаваемая БД будет полностью задокументировано. Также возможен обратный инжиниринг имеющихся БД с помощью построения модели непосредственно на основе ее таблиц. Erwin поддерживает Oracle, Microsoft SQL Server, Sybase, Informix и другие. Одна и та же модель может использоваться для проектирования нескольких БД (или переноса приложения с платформы одной системы управления БД на другую.

Источники

  1. Википедия: Базы данных
  2. определение БД
  3. Проектирование баз данных
  4. Этапы проектирования БД
  5. CASE
  6. Реферат Case средства
  7. Википедия: Erwin
  8. сайт про Erwin

 

Количество просмотров публикации: —

portalnp.ru

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

Обработка счетов. Электронная торговля.
Анализ данных. Управление знаниями. Все
это невозможно без использования баз
данных. Системы с архитектурой
клиент/сервер строятся на основе
реляционных серверных СУБД. Приложения
для Internet и интрасетей осуществляют
доступ и динамическое обновление данных.
Пакеты программ необходимо адаптировать
и интегрировать с существующими
системами. Хранилища данных объединяют
и интегрируют множество баз данных,
обеспечивая необходимые бизнесу гибкость
и интеллектуальность. Успех применения
всех этих приложений зависит от того,
насколько хорошо спроектирована база
данных.

PLATINUM ERwin — мощное и простое в использовании
средство конструирования баз данных
завоевавшее широкое признание и
популярность. Оно обеспечивает высочайшую
продуктивность труда при разработке и
сопровождении приложений с использованием
баз данных.
На протяжении всего
процесса — от логического моделирования
требований к информации и бизнес-правил,
которые определяют базу данных, до
оптимизации физической модели в
соответствии с заданными характеристиками
— ERwin позволяет наглядно отобразить
структуру и основные элементы вашей
БД.
ERwin — это не просто мощное средство
проектирования, но и инструмент
разработки, способный автоматически
создавать таблицы и генерировать тысячи
строк текста хранимых процедур и
триггеров для всех популярных СУБД.
Революционная технология Complete-Compare
(Завершить-Сравнить) позволяет организовать
итеративную разработку, поддерживая
постоянную согласованность модели и
базы данных. Благодаря интеграции с
популярными средами разработки программ,
ERwin позволяет ускорить создание приложений
для обработки данных.
ERwin может
масштабироваться путем интеграции с
продуктом PLATINUM ModelMart. Эта мощная система
управления моделями позволяет
проектировщикам баз данных разработчикам
приложений и пользователям коллективно
работать с информацией о моделях ERwin.
Благодаря возможностям разбиения на
фрагменты, а также совместного и
многократного использования моделей,
может быть повышена эффективность
моделирования и обеспечено соблюдение
корпоративных стандартов.

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

Развитые средства моделирования
помогают лучше спроектировать базу
данных. Предусмотрены возможности
манипулирования атрибутами путем их
буксировки, внесения изменений и
нормализации «на лету». Средства
редактирования непосредственно на
диаграммах позволяют вносить в модель
изменения, не открывая специальных
диалоговых окон. Навигация по отношениям
обеспечивает быстрое перемещение в
больших моделях для перехода к родительским
или дочерним объектам. Формируемые
системой отчеты позволяют быстро
проверить корректность спроектированной
базы данных.
ERwin — это не что гораздо
большее, чем просто инструмент для
«рисования»; он автоматизирует
процесс проектирования. Например, ERwin
предусматривает возможность создания
каталога наиболее часто используемых
атрибутов, что обеспечивает согласованность
имен и описаний по всему проекту.
Представления БД поддерживаются как
интегрированные компоненты модели, что
позволяет автоматически отображать в
их описаниях изменения, внесенные в
базовые таблицы. Автоматический перенос
ключей обеспечивает ссылочную целостность
базы данных.
Кроме того, ERwin позволяет
работать с большими моделями
общекорпоративного масштаба, разбивая
их на фрагменты и легко управляемые
подмножества, предоставляя отдельным
специалистам возможность сосредоточить
свои усилия в определенной области.
Возможность сохранения отображений
позволяет хранить множество представлений
одной предметной области, ориентированных
на различную целевую аудиторию.
Созданные
с помощью ERwin модели данных можно
редактировать, просматривать и
распечатывать различными способами. В
состав ERwin входит RPTwin — простая в
использовании, оснащенная графическим
интерфейсом утилита для формирования
отчетов и встроенное средство для
просмотра с настраиваемыми режимами
,которые обеспечивают полный контроль
над отображением содержимого отчетов.
Кроме этого, уникальный интерфейс,
построенный на использовании шаблонов,
позволяет реализовать единые стандарты
проектирования и отображать настройки
для всех моделей.

Автоматическая генерация БД
ERwin
— не только лучший инструмент для
проектирования баз данных, но и средство
для их быстрого создания. ERwin оптимизирует
модель в соответствии с физическими
характеристиками целевой базы данных.
В отличие от других инструментальных
средств ERwin автоматически поддерживает
согласованность логической и физической
схем и осуществляет преобразование
логических конструкций, таких как
отношения многие-ко-многим, в их реализацию
на физическом уровне.
ERwin устанавливает
естественную динамическую связь между
моделью и базой данных, что позволяет
реализовать как прямой, так и обратный
инжиниринг. Используя эту связь, ERwin
автоматически генерирует таблицы,
представления, индексы, правила
поддержания целостности ссылок (первичных
и внешних ключей), устанавливает значения
по умолчанию и ограничения для
доменов/столбцов. В состав ERwin включен
целый ряд оптимизированных шаблонов
триггеров, обеспечивающих целостность
ссылок, и мощный макроязык, который
позволяет создавать собственные триггеры
и хранимые процедуры. Таким образом
могут быть автоматически сформированы
тысячи строк кода, что обеспечивает
непревзойденную продуктивность
разработки на основе моделей.
Средства
расчета объема позволяют точно оценить
первоначальный размер и характер роста
базы данных или хранилища, облегчая
эффективное распределение ресурсов
системы и планирование мощности.
База
данных может быть спроектирована и
создана без написания отдельных
SQL-предложений типа CREATE TABLE или INDEX.
Поскольку физическая схема формируется
на основе описательной логической
модели, ваше приложение будет сразу же
полностью документировано. ERwin позволяет
также проводить обратный инжиниринг
существующих баз данных путем построения
модели непосредственно на основе ее
таблиц. Таким образом можно получить
четкое представление о структуре и
содержании существующего приложения.

ERwin поддерживает все наиболее популярные
реляционные СУБД, включая Oracle, Microsoft SQL
Server, Sybase, DB2 и Informix. Одна и та же модель
может быть использована для создания
нескольких баз данных или для переноса
приложения с платформы одной СУБД на
другую.

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

studfiles.net

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

spravochnick.ru

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

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

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

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

Рисунок
3.1 Характеристики БД

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

Рисунок
3.2 Схемы классического (а) и современного
подходов

при
построении БД

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

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

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

Рисунок
3.3 Схема создания использования БД

Архитектура субд

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

Рисунок
3.4 Структура СУБД

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

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

СУБД имеет два
режима работы:

Проектирование
БД состоит в построении комплекса
взаимосвязанных моделей данных.

Методология проектирования баз данных

Существует много
разновидностей методологии рассмотрения
баз данных в классическом подходе,
однако чаще всего придерживаются
методологии ANSI/SPARC, схема которой
представлена на рисунке 3.5.

На рисунке 3.5
показана совокупность процедур
проектирования централизованной БД,
которые можно объединить в четыре этапа.

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

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

Рисунок
3.5 Схема этапов проектирования БД

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

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

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

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

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

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

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

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

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

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

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

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

Основными причинами
низкой эффективности проектируемых БД
могут быть:

  • недостаточно
    глубокий анализ требований (начальные
    этапы проектирования), включая их
    семантику и взаимосвязь данных;

  • большая
    длительность процесса структурирования,
    делающая этот процесс утомительным и
    трудно выполняемым при ручной обработке.

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

studfiles.net