рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

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

Этапы проектирования баз данных - раздел Информатика, Курс лекций по информатике Тема: Базы данных, Банки Данных, Системы Управления Базами Данных — СУБД Создание И Внедрение В Практику Современных Информационных Систем Автоматизир...

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

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

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

Такое представление уровней данных не единственное. Существуют и другие варианты многоуровневого представления данных. Так, в соответствии с предложениями исследовательской группы по системам управления данными Американского национального института стандартов ANSI/X3/SPARC, а также CODASYL (Conference on Data Systems Languages), как правило, выделяется три уровня представления данных:

1. внешний уровень (с точки зрения конечного пользователя и прикладного программиста),

2. концептуальный уровень (с точки зрения СУБД),

3. внутренний уровень (с точки зрения системного программиста).

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

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

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

При проектировании БД на внешнем уровне необходимо изучить:

ü функционирование объекта управления, для которого проектируется БД,

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

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

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

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

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

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

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

Рис. 5. Схема взаимосвязи уровней представления данных в БД

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

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

– Конец работы –

Эта тема принадлежит разделу:

Курс лекций по информатике Тема: Базы данных, Банки Данных, Системы Управления Базами Данных — СУБД

ГОУ ВПО Вологодский государственный технический университет факультет промышленного менеджмента..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Этапы проектирования баз данных

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

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

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

Первый этап — базы данных на больших ЭВМ
История развития СУБД насчитывает около 40 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам сис

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

Третий этап - распределенные базы данных
Хорошо известно, что история развивается по спирали, поэтому после процесса «персонализации» начался обратный процесс — интеграция. Множится количество локальных сетей, все больше информации переда

Четвертый этап - Интранет
Этот этап характеризуется появлением новой технологии доступа к данным — Интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования

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

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

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

Основные функции группы администратора БД
1. Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса (доступности, секретности) информации, определение потребностей пользователей, опре

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

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

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

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

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

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

Основные средства субд
Основными средствами СУБД являются: 1. средства задания (описания) структуры БД; 2. средства конструирования экранных форм, предназначенных для ввода данных, просмотра и их обрабо

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

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

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

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

Еще раз о реляционной модели данных
Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных.

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

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

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

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

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги