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

Автор работы: Пользователь скрыл имя, 25 Марта 2011 в 17:17, реферат

Описание работы

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

Содержание работы

Введение……………………………………………………… 2

Реляционная модель данных………………………………………4

Цели и задачи проектирования………………………………….8

Структура процесса проектирования………………………….9

Технология ведения информационной системы………………..11

Заключение……………………………………………………13

Список литературы…………………………………………...14

Файлы: 1 файл

СОДЕРЖАНИ.docx

— 39.60 Кб (Скачать файл)

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

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

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

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

• требуемые объемы основной и дисковой памяти;

• трудоемкость разработки программных средств окружения СУБД;

• трудоемкость реализации приложений;

• затраты на обучение персонала;

• стоимость эксплуатации, информационной системы;

• возможность совмещения разработки БД с ранее выполненными программными реализациями;

• прогнозируемые сроки  реализации информационной системы.

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

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

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

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

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

• ввод информации в  систему;

• защита данных;

• управление использованием данных;

• управление эффективностью системы.

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

ТЕХНОЛОГИЯ ВЕДЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

Термин «реляционный»  означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».

Для лучшего понимания  РМД следует отметить три важных обстоятельства:

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

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

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

ЛИТЕРАТУРА

1) http://www.fio.ru/- web-сайт Федерации Интернет образования.

2) http://www.citforum.ru/database/foxpro.shtml - материалы по БД

3) http://db.informika.ru/ - электронный справочник

4) http://www.inftech.webservis.ru/ - web-сайт Информационных технологий.

5) www.e-russia.ru - web-сайт, посвящённый содержанию, проблемам и обоснованию необходимости решения ФЦП «Электронная Россия» программными методами.

6) http://ccc.ru/elro/about.html - материалы об Электронной России: дискуссионный центр.

7) http://www.e-rus.org/articles/meaning_programm.shtml -Официальный текст программы «Электронная Россия»

8) www.hse.ru/~erussia - web-сайт ФЦП «Электронная Россия». 
 
 
 
 
 
 
 
 
 
 
 
 
 

Информация о работе Реляционная модель данных