Автор работы: Пользователь скрыл имя, 23 Марта 2014 в 13:09, контрольная работа
База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области. Под предметной областью принято понимать некоторую область человеческой деятельности или область реального мира, подлежащих изучению для организации управления и автоматизации, например, предприятие, вуз и.т.д. Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, наполнения, обновления и удаления баз данных.
Введение………………………………………………………………….3
1. Принципы построения баз данных…………………………………..4
2. Методы проектирования БД………………………………………….7
Заключение……………………………………………………………..19
Список литературы…………………………………………………….20
ИНФОРМАТИКА И ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
В ПРОФЕССИНАЛЬНОЙ ДЕЯТЕЛЬНОСТИ
Тема 47. Методы проектирования баз данных
Оглавление
Введение…………………………………………………………
1. Принципы построения баз данных…………………………………..4
2. Методы проектирования БД………………………………………….7
Заключение……………………………………………………
Список литературы……………………………………………………
Введение
Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.
Традиционно фиксация данных осуществляется с помощью конкретного средства общения, например, с помощью естественного языка на конкретном носителе.
В настоящее время успешное функционирование различных фирм, организаций и предприятий просто не возможно без развитой информационной системы, которая позволяет автоматизировать сбор и обработку данных. Обычно для хранения и доступа к данным, содержащим сведения о некоторой предметной области, создается база данных.
База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.
Под предметной областью принято понимать некоторую область человеческой деятельности или область реального мира, подлежащих изучению для организации управления и автоматизации, например, предприятие, вуз и.т.д.
Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, наполнения, обновления и удаления баз данных.
Программы, с помощью которых пользователи работают с БД, называются приложениями.
Цель работы – проанализировать методы проектирования баз данных.
1. Принципы построения баз данных
К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования1.
1. Высокое быстродействие
(малое время отклика на
Время отклика - промежуток времени от момента запроса к БД до фактического получения данных. Похожим является термин время доступа - промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их. Часто операции записи, удаления и модификации данных называют операцией обновления.
2. Простота обновления данных.
3. Независимость данных.
4. Совместное использование данных многими пользователями.
5. Безопасность данных - защита
данных от преднамеренного или
непреднамеренного нарушения
6. Стандартизация построения и эксплуатации БД (фактически СУБД).
7. Адекватность отображения
данных соответствующей
8. Дружелюбный интерфейс пользователя.
Важнейшими являются первые два противоречивых требования: повышение быстродействия требует упрощения структуры БД, что, в свою очередь, затрудняет процедуру обновления данных, увеличивает их избыточность.
Независимость данных - возможность изменения логической и физической структуры БД без изменения представлений пользователей.
Независимость данных предполагает инвариантность к характеру хранения данных, программному обеспечению и техническим средствам. Она обеспечивает минимальные изменения структуры БД при изменениях стратегии доступа к данным и структуры самих исходных данных. Это достигается «смещением» всех изменений на этапы концептуального и логического проектирования с минимальными изменениями на этапе физического проектирования.
Безопасность данных включает их целостность и защиту.
Целостность данных - устойчивость хранимых данных к разрушению и уничтожению, связанных с неисправностями технических средств, системными ошибками и ошибочными действиями пользователей.
Она предполагает:
1. отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;
2. защиту от ошибок при обновлении БД;
3. невозможность удаления (или каскадное удаление) связанных данных разных таблиц;
4. неискажение данных
при работе в
5. сохранность данных при сбоях техники (восстановление данных).
Целостность обеспечивается триггерами целостности – специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться2:
1. введением системы паролей;
2. получением разрешений от администратора базы данных (АБД);
3. запретом от АБД на доступ к данным;
4. формирование видов - таблиц,
производных от исходных и
предназначенных конкретным
Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language - SQL, часто называемого SQL2.
Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).
2. Методы проектирования БД
Целью проектирования БД является адекватное отображение в базе данных сути предметной области, рассматриваемой с точки зрения решения задачи автоматизации.
В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни её архитектуры. Распространены два основных подхода к проектированию баз данных: «нисходящий» и «восходящий».
Известен также подход «смешанной стратегии» - сначала «восходящий» и «нисходящий» методы используются для разных частей модели, после чего все подготовленные фрагменты собираются в единое целое.
Метод восходящего проектирования БД
При «восходящем» подходе осуществляют структурное проектирование снизу-вверх. Этот процесс называют процессом синтеза, попыткой получения целого, адекватно отображающего описание предметной области, на основе описания составляющих его частей.
Этапы проектирования БД методом «восходящего» проектирования представлены на рисунке 1.
Рисунок 1 - Этапы проектирования БД методом «восходящего» проектирования
Работа для реляционной БД начинается с определения свойств объектов (атрибутов сущностей) предметной области, которые на основе анализа существующих между ними связей группируются в реляционные отношения (таблицы), отображающие эти объекты (в том случае, если мы проектируем структуру реляционной БД).
Как правило, получают 2 - 3 реляционных отношения, связанных между собой.
Избыточность данных в ненормализованной схеме – повторение данных в БД.
Для того чтобы полученная структура БД (ДЛМ) не обладала различными аномалиями при добавлении, обновлении или удалении данных вследствие их избыточности, необходимо осуществить проверку каждой полученной схемы отношения, как минимум, на соответствие 3НФ. Если схемы отношений не соответствуют этому условию, а они, как правило, не соответствуют, необходимо проводить процесс нормализации.
Значительный объем мероприятий по нормализации схем реляционных отношений даже дал второе название методу «восходящего» проектирования. Этот метод часто называют методом «нормализации». Основы теории нормализации создал Э. Кодд3.
Нормализация – это процесс проектирования в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем.
Совокупность схем отношений называется схемой реляционной БД.
Нормализация исключает избыточность и аномалии в БД.
Этапы проектирования БД методом нормализации:
Выделяют следующие этапы4:
1. Определение всех атрибутов,
сведения о которых будут
2. Составление списка сырых данных в виде схем реляционных отношений. Полученная в итоге схема отношений находятся в нулевой нормальной форме (0НФ).
3. Приведение схемы отношения к 1НФ
Опр. 1НФ: Схема отношения находится в 1НФ тогда и только тогда, если все атрибуты схемы имеют атомарное значение и в схеме отношений отсутствуют повторяющиеся группы.
Опр.: повторяющаяся группа – один или более элементов данных, которые имеют более одного значения для одного значения части ключа. Рассматривается, если первичный ключ составной.
Разбиение схемы отношения на атомарные атрибуты.
Удаление повторяющихся групп.
4. Изучение смысла (семантики) данных и определение набора атрибутов – потенциального (уникального) ключа отношения. Может быть несколько уникальных ключей.
Уникальный (потенциальный) ключ – атрибут или набор атрибутов, который полностью и однозначно определяет значения других атрибутов.
5. Если отношение обладает
несколькими потенциальными
6. Выявление функциональных зависимостей между атрибутами нормализуемой схемы отношения.
Опр.: функциональной зависимостью атрибута В (набора атрибутов) отношения R от атрибута (набора атрибутов) А отношения R, обозначаемой
R.A -> R.B A->B
называется такая связь между атрибутами отношения, что в каждый момент времени каждому значению атрибута (набору атрибутов) В соответствует только одно значение атрибута (набора атрибутов) А.
Однако для заданного значения атрибута В может существовать несколько различных значений атрибута А.
Таким образом, если из семантики предметной области нам известно значение атрибута А, то мы в предметной области однозначно можем определить значение атрибута В.
ФЗ является смысловым свойством атрибутов отношения.
В отношении м.б. выявлено много функциональных зависимостей, т.е. в отношении м.б. выявлено много детерминантов.
Опр.: ключевой атрибут – атрибут, входящий в состав первичного ключа
Опр.: не ключевой атрибут – атрибут, не входящий в состав первичного ключа.
Опр.: частичная ФЗ – это зависимость не ключевого атрибута от части составного первичного ключа.
Опр.: полная ФЗ – это зависимость не ключевого атрибута от всего составного первичного ключа.
Имеет смысл рассматривать полную и частичную ФЗ в том случае, если ПК – составной.
7. Приведение схемы отношения к 2НФ
Технология приведения ко 2НФ:
1) В отдельную схему отношения выносится составной первичный ключ и те атрибуты, которые функционально полно зависят от него. Если таких атрибутов нет, то первичный ключ выносится один.
2) В отдельную схему
выносится часть первичного
Сколько частей первичного ключа образовали частичные ФЗ, столько схем получаем
3) Исходная схема удаляется.
8. Определение транзитивных
зависимостей в каждом
Опр.: транзитивная зависимость – атрибут С отношения R транзитивно зависит от атрибута А отношения R, если для атрибутов А, В, С выполняется условие существования следующих ФЗ:
А -> B
B -> C
при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С.
9. Удаление транзитивных зависимостей путем декомпозиции схем отношений
10 Определение условий
необходимости анализа схем
Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ.
Опр.: Отношение находится в НФБК, если оно находится в 3НФ и каждый детерминант отношения является потенциальным ключом отношения.
Опр.: Детерминантом ФЗ называется атрибут (набор атрибутов), расположенный в левой части ФЗ, т.е. от детерминанта функционально полно зависит некоторый другой атрибут (атрибуты)
В отношении может быть несколько детерминантов.
Ситуация, когда отношение будет находиться в 3НФ, но не в НФБК, возникает при условии, что отношение имеет два (или более) возможных (потенциальных) ключа, которые являются составными и имеют общий атрибут.