3.Реляционная модель данных.

Понятие реляционной (англ. relation – отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.

Базовые понятия реляционной модели данных

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

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

целочисленные типы;

вещественные типы;

строковые типы;

типы данных для денежных величин;

типы данных для временных величин;

типы двоичных объектов (не имеет аналогов в языках программирования, и обозначаются Blob)

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

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

4.

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

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

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

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

-построение информационно-логической модели данных предметной области;

-определение логической структуры реляционной базы данных;

-конструирование таблиц базы данных;

-создание схемы данных;

-ввод данных в таблицы (создание записей);

-разработка необходимых форм, запросов, макросов, модулей, отчетов;

-разработка пользовательского интерфейса.

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

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

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

Сразу устанавливаются типовые объекты предметной области.

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

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

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

Рассмотрим формальные правила выделения информационных объектов:

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

-определить функциональные зависимости между атрибутами;

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

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

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

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

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

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

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

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

53. Понятия БД: сущность, поле, атрибут, , ключ, связь, домен, кортеж.

54. Назначение системы управления базой данных (СУБД). Примеры различных СУБД.

55. Электронные таблицы. Сущность обработки данных в электронных таблицах?

56. Типы данных. в Ms Excel. Абсолютная и относительная адресация.

57. Основные методы проектирования ИС.

58. Назначение CASE-технологий.

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

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:

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

-возможность повторного использования компонентов разработки.

-поддержание адаптивности и сопровождения ЭИС.

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

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

-возможность коллективной разработки ЭИС в режиме реального времени.

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

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

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

В настоящее время CASE-системы прочно вошли в практику программной индустрии. К средствам, распространяемым на Российском рынке относятся Bpwin, Silverrun, Oracle Designer, основанные на структурном подходе к проектированию, а также Ratoinal Rose, Re Think, основные на объектно-ориентированном подходе.

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

(Реинжиниринг бизнес-процессов (BPR – business process reengineering) – фундаментальное переосмысление и радикальное перепланирование критических бизнес-процессов, имеющее целью резко улучшить их выполнение с точки зрения, качества и скорости обслуживания).