Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Средства автоматизации проектирования.
Для автоматизации проектирования и разработки ИС в 70-80-е гг. широко применялась структурная методология, означающая использование формализованных методов описания разрабатываемой системы и принимаемых технических решений. При этом использовались графические средства описания различных моделей ИС с помощью схем и диаграмм. При ручной разработке ИС такие графические модели разрабатывать и использовать весьма трудоемко. Это послужило появлению программно-технологических средств, получивших название CASE-средства и реализующих CASE-технологии создания и сопровождения ИС. CASE-средства представляют собой программные средства, поддерживающие процессы создания и сопровождения ИС, такие как анализ и формулировка требований, проектирование БД и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и проектом. CASE-систему можно определить как набор CASE-средств, имеющих определенное функциональное предназначение и выполненных в рамках единого программного продукта. CASE-технология обычно определяется как методология проектирования ИС плюс инструментальные средства, позволяющие наглядно моделировать предметную область, анализировать ее модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения для пользователей. Основная цель CASE-систем и средств состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих этапов разработки, а также автоматизировать весь процесс создания программных систем. В последнее время все чаще разработка программ начинается с некоторого предварительного варианта системы. В качестве такого варианта может выступать специально для этого разработанный прототип либо устаревшая и неудовлетворяющая новым требованиям система. В последнем случае для восстановления знаний о программной системе с целью последующего их использования применяют повторную разработку – реинжиниринг. Современные CASE-системы не ограничиваются только разработкой, а чаще всего обеспечивают и повторную разработку. Это существенно ускоряет разработку приложений и повышает их качество. Полнофункциональная объектно-ориентированная система должна решать задачи анализа и моделирования, проектирования, разработки, а также иметь эффективную инфраструктуру, обеспечивающую сервисом превые 3 основные задачи.
Этапы проектирования. Процесс проектирования базы данных – это процесс, допускающим возврат к предыдущим этапам для пересмотра ранее принятых решений и включает следующие этапы: 1. Выделение сущностей и связей между ними. 2. Построение диаграмм ER-типа с учетом всех сущностей и их связей. 3. Формирование набора предварительных отношений с указанием предполагаемого первичного ключа для каждого отношения и использованием диаграмм ER-типа. 4. Добавление неключевых атрибутов в отношения. 5. Приведение предварительных отношений к нормальной форме Бойса-Кодда, например, с помощью метода нормальных форм. 6. Пересмотр ER-диаграмм в следующих случаях: • некоторые отношения не приводятся к нормальной форме Бойса-Кодда; • некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях. После преобразования ER-диаграмм осуществляется повторное выполнение предыдущих этапов проектирования (возврат к этапу 1). Одним из узловых этапов проектирования является этап формирования отношений. Рассмотрим процесс формирования предварительных отношений, составляющих первичный вариант схемы БД. В рассмотренных выше примерах связь ВЕДЕТ всегда соединяет две сущности и поэтому является бинарной. Сформулированные ниже правила формирования отношений из диаграмм ER-типа распространяются именно на бинарные связи. Поэтому, когда речь идет о связях, слово «бинарные» далее опускается. Проблемы проектирования. Проектирование ИС, включающих в себя БД, осуществляется на физ. и лог. уровнях. Решение проблем проектирования на физ. уровне во многом зависит от используемой СУБД, зачастую автоматизирована и скрыта от пользователя. Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форма для ввода и редактирования данных в базе и решения ряда др. задач.
Решение задач логического проектирования БД в основном определяется спецификой задач предметной области. Наиболее важной здесь является проблема структуризации данных. При проектировании структур данных для автоматизированных систем можно выделить 3 основных подхода: 1) сбор информации об объектах решаемой задачи в рамках одной таблицы и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений; 2) формулирование знаний о системе и требований к обработке данных, получение с помощью CASE-системы готовой схемы БД или даже готовой прикладной ИС; 3) структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности правил и рекомендаций. Следует различать простое и избыточное дублирование данных. Наличие первого из них допускается в БД, а избыточное дублирование данных может приводить к проблемам при обработке данных. Пример неизбыточного дублирования данных представляет собой отношение С (Т) с атрибутами «сотрудник» и «телефон». для сотрудников, находящихся в одном помещении, номера телефонов совпадают. Номер телефона 4328 встречается несколько раз, хотя для каждого служащего номер телефона уникален. поэтому ни один из номеров не является избыточным. С_Т
Пример избыточного дублирования представляет отношение С_Т_Н, которое в отличие от отношения С_Т дополнено атрибутом Н_комн. Все служащие в одной комнате имеют один телефон. Следовательно, в рассматриваемом отношении имеется избыточное дублирование данных. С_Т_Н
Избыточное дублирование данных создает проблеиы при обработке кортежей отношения, названные Коддом «аномалиями обновления отношений». Реляционная модель. Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение. Отношение представляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица. Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам — атрибуты отношения. С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно деление одного, информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов. Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми. Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей. Примерами зарубежных реляционных СУБД являются следующие:, DB2 (IBM), R:BASE (Microrim), FoxPro, Paradox и dBASE for Windows (Borland),, Visual FoxPro и Access (Microsoft), Clarion (Clarion Software), и Oracle (Oracle). К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech (МИФИ).
|
|||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2017-01-25; просмотров: 172; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.215.183.194 (0.027 с.) |