Этап 1. Уточнение задач

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

Этап 2. Последовательность выполнения задач

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

Этап 3. Анализ данных

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

Этап 4. Определение структуры данных

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

Этап 5. Разработка макета приложения и пользовательского интерфейса

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

Этап 6. Создание приложения

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

Этап 7. Тестирование и усовершенствование

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

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

Основы методологии проектирования прикладных программ были заложены в 60-е годы XX века известными специалистами Дж. Мартином, Э. Йордоном и Д. Константайном. На заре применения вычислительной техники разработка программ, поиск и устранение ошибок были настолько дорогостоящими, что опытные программисты-практики часто советовали: прежде чем написать хоть одну строку программы, стоит потратить не менее 60% всего необходимого для разработки времени на проектирование.

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

Рассмотрим основные этапы проектирования БД

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

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

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

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

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

Определение таблиц, которые должна содержать база данных.

Определение необходимых в таблице полей.

Задание индивидуального значения каждому полю.

Определение связей между таблицами.

Обновление структуры базы данных.

Добавление данных и создание других рбъектов.6азы данных.

Использование средств анализа в Microsoft Access.

1. Определение цели создания базы данных

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

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

2. Определение таблиц, которые должна содержать база данных

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

При проектировании таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами.

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

Каждая таблица должна содержать информацию только на одну тему.

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

Наименование параметра	Значение
Тема статьи:	Этапы проектирования баз данных
Рубрика (тематическая категория)	Связь

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

Темы: этапы проектирования баз данных, проектирование базы данных на базе модели типа объект-отношение

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

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

Перед созданием базы данных крайне важно располагать описанием выбранной предметной области, ĸᴏᴛᴏᴩᴏᴇ должно охватывать реальные объекты и процессы, определить всœе необходимые источники информации для удовлетворения предполагаемых запросов пользователœей и определить потребности в обработке данных.

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

Этапы проектирования и создания базы данных определяются следующей последовательностью:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 Проектирование базы данных на базе модели типа объект-отношение

Имеется целый ряд методик создания информационно-логических моделœей. Одна из наиболее популярных в настоящее время методик при разработке моделœей использует ERD (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют ʼʼобъект - отношениеʼʼ либо ʼʼсущность - связьʼʼ. Модель ERD была предложена Питером Пин Шен Ченом в 1976 ᴦ. К настоящему времени разработано несколько ее разновидностей, но всœе они базируются на графических диаграммах, предложенных Ченом. Диаграммы конструируются из небольшого числа компонентов. Благодаря наглядности представления они широко используются в CASE-средствах (Computer Aided Software Engineering).

Рассмотрим используемую терминологию и обозначения.

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

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

‣‣‣ иметь уникальное имя; причем к этому имени должна всœегда применяться одна и та же интерпретация (определœение сущности). И наоборот: одна и та же интерпретация не может применяться к различным именам, в случае если только они не являются псевдонимами;

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

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

Сущность должна быть независимой либо зависимой. Признаком зависимой сущности служит наличие у нее наследуемых через связь атрибутов (рис. 1.).

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

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Одна из участвующих в связи сущностей - независимая, принято называть родительской сущностью, другая - зависимая, принято называть дочерней или сущностью-потомком. Как правило, каждый экземпляр родительской сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров дочерней сущности. Каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, экземпляр сущности-потомка может существовать только при существовании сущности-родителя.

Связи дается имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Каждая связь имеет определœение. Определœение связи образуют соединœением имени сущности-родителя, имени связи, выражения степени связи и имени сущности-потомка.

К примеру, связь продавца с контрактом должна быть определœена следующим образом:

‣‣‣ продавец может получить вознаграждение за один или более Контрактов;

‣‣‣ контракт должен быть инициирован ровно одним Продавцом.

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

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

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

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

Характер идентификации отображается в диаграмме на линии связи (рис. 4).

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

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

Сегодня на базе подхода Чена создана методология IDEF1X, которая разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEFlX-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

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

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

Идентифицирующая связь между сущностью-родителœем и сущностью-потомком изображается сплошной линией. На рис. 5: №2 - зависимая сущность, Связь 1 - идентифицирующая связь. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи должна быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).

Штриховая линия изображает неидентифицирующую связь. На рис. 5: №4 - независимая сущность, Связь 2 - неидентифицирующая связь. Сущность-потомок в неидентифицируюшей связи будет независимой от идентификатора, в случае если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, ĸᴏᴛᴏᴩᴏᴇ может существовать для каждого экземпляра сущности-родителя). В IDEF1X бывают выражены следующие мощности связей:

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

‣‣‣ каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

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

‣‣‣ каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Мощность связи обозначается, как показано на рис. 6 (мощность по умолчанию - N).

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

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

Этапы проектирования баз данных - понятие и виды. Классификация и особенности категории "Этапы проектирования баз данных" 2017, 2018.

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

Этапы разработки базы данных:

1. Постановка задачи.

2. Разработка информационно-логической (инфологической) модели.

3. Выбор СУБД. Разработка логической модели базы данных.

4. Разработка программного обеспечения базы данных.

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

Рассмотрим эти этапы более подробно.

1-й этап. Постановка задачи

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

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

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

2-й этап. Разработка информационно-логической (инфологической) модели

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

Нередко для описания инфологической модели используются диаграммы "сущность-связь" (ER-диаграммы).

3-й этап. Выбор СУБД. Разработка логической модели базы данных

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

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

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

4-й этап. Разработка программного обеспечения базы данных

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

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

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

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

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

Вопросы для самоконтроля:

1. Перечислите этапы разработки базы данных.

2. На каком этапе производится первичное обучение пользователей?

3. На каком этапе определяется перечень входной и выходной информации и детальные характеристики этой информации?

4. На каком этапе определяются цели разработки БД?

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

1.5 Особенности архитектуры информационных систем. Одно – двух – и трехуровневые системы

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

· централизованная архитектура;

· архитектура "файл-сервер";

· архитектура "клиент – сервер";

· трехзвенная (многозвенная) архитектура "клиент – сервер"

Рассмотрим эти технологии более подробно.

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

АМУРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

(ГОУВПО «АмГУ»)

КОНТРОЛЬНАЯ РАБОТА

по дисциплине «Информационные системы в экономике»

на тему: «Принципы построения и этапы проектирования баз данных»

Исполнитель

студент группы С – 81 Н.А. Вохмянина

Руководитель

доцент, к. т. н. Д. Г. Шевко

Благовещенск 2010

Введение

1. Принципы построения баз данных

2. Концепции построения баз данных

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

Библиографический список

ВВЕДЕНИЕ

Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

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

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

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

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

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

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

1. ПРИНЦИПЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ

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

1. Высокое быстродействие (малое время отклика на запрос).

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

2. Простота обновления данных.

3. Независимость данных.

4. Совместное использование данных многими пользователями.

5. Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

6. Стандартизация построения и эксплуатации БД (фактически СУБД).

8. Дружелюбный интерфейс пользователя.

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

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

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

Безопасность данных включает их целостность и защиту.

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

Она предполагает:

1. отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

2. защиту от ошибок при обновлении БД;

3. невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

4. неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;

5. сохранность данных при сбоях техники (восстановление данных).

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

1. введением системы паролей;

2. получением разрешений от администратора базы данных (АБД);

4. формирование видов - таблиц, производных от исходных и предназначенных конкретным пользователям.

Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language - SQL, часто называемого SQL2.

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).

2. КОНЦЕПЦИЯ ПОСТРОЕНИЯ БАЗЫ ДАННЫХ

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

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

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

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

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

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

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

Проектирование баз данных происходит в четыре этапа.

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

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

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

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