Контрольная работа по "Информатике"

Сахарова А. А.          группа БЭКН ЭЗ 11                № з/книжки 110430112 06.06.2012

Оглавление

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

Инфологическое  проектирование 4

Определение требований к операционной обстановке 6

Выбор СУБД и  других программных средств 6

Логическое  проектирование БД 7

Физическое  проектирование БД 7

Нормализация  отношений 8

Автоматизированные  технологии проектирования баз данных 9

Вариант 13. Формирование реестра заказов 11

Список литературы 19

 

 

Вариант 6. Основы проектирования реляционных баз  данных

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

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

1. Корректность схемы БД, т.е. каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных.
2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и другие ресурсы вычислительной системы).
3. Эффективность функционирования (соблюдение ограничений на время реакции системы на запрос и обновление данных).
4. Защита данных (от аппаратных и программных сбоев и несанкционированного доступа).
5. Простота и удобство эксплуатации.
6. Гибкость, т.е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей.

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

Процесс проектирования включает в себя следующие этапы:

1. Инфологическое проектирование.
2. Определение требований к операционной обстановке, в которой будет функционировать информационная система.
3. Выбор системы управления базой данных (СУБД) и других инструментальных программных средств.
4. Логическое проектирование БД.
5. Физическое проектирование БД.

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

Инфологическое  проектирование

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

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

Основные подходы к созданию инфологической модели предметной области:

• Функциональный подход к проектированию БД. Этот метод реализует принцип "от задач" и применяется тогда, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.
• Предметный подход к проектированию БД применяется в тех случаях, когда у разработчиков есть чёткое представление о самой ПО и о том, какую именно информацию они хотели бы хранить в БД, а структура запросов не определена или определена не полностью. Тогда основное внимание уделяется исследованию ПО и наиболее адекватному её отображению в БД с учётом самого широкого спектра информационных запросов к ней.
• Проектирование с использованием метода "сущность-связь" – (ER–method) является комбинацией двух предыдущих и обладает достоинствами обоих. Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает её на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения запросов отдельной группы будущих пользователей или решения отдельной задачи (подзадачи). Каждое локальное представление моделируется отдельно, затем они объединяются.

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

Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).

Для каждой сущности выбираются свойства (атрибуты). Различают:

1. Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
2. Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
3. Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности).
4. Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).

По типу различают множественные  связи "один к одному" (1:1), "один ко многим" (1:n) и "многие ко многим" (m:n). ER–диаграмма, содержащая различные типы связей, приведена на рис. 1. Обратите внимание, что обязательные связи на рис. 1 выделены двойной линией.

Рис.1. ER–диаграмма с примерами  типов множественных связей

Определение требований к операционной обстановке

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

Выбор СУБД и других программных средств

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

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

Логическое проектирование БД

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

Результатом выполнения этого  этапа являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языках определения данных (DDL, Data Definition Language), поддерживаемых данной СУБД.

Физическое проектирование БД

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

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

Нормализация  отношений

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

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

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

•было неделимым;

•не содержало повторяющихся  групп.

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

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

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

Модель неделима и не содержит повторяющихся групп, следовательно, данная модель находится в первой нормальной форме.

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

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

Автоматизированные  технологии проектирования баз данных

Проектирования БД является сложным итерационным процессом. Автоматизировать данный процесс можно с помощью современных CASE-средств (средств автоматизации проектирования).

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

Современные CASE-средства позволяют создавать синтаксические модели базы данных на этапах 4 и 5, исходя из инфологической модели предметной области, построенной человеком (проектировщиком БД) на этапе 2. Очевидно, что этапы 1 и 3 полностью не формализуются. Этап 2 допускает лишь частичную автоматизацию, поскольку только человек способен построить в своей голове инфологическую модель предметной области, а лишь потом для описания этой модели применить соответствующие CASE-средства.