Реферат на тему Основные этапы разработки базы данных. Microsoft Access. Правила нормализации.

Содержание:

ВВЕДЕНИЕ 3

1.Основные этапы разработки базы данных. 4

2. Характеристика базы данных в Microsoft Access 8

3. Правила нормализации. 17

ЗАКЛЮЧЕНИЕ 21

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 23

Введение:

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

В процессе совершенствования этой программы были внесены уникальные возможности. Данные могут быть представлены в виде таблиц или диаграмм. И если принять во внимание, что данной программой может пользоваться любой пользователь (от новичка до профессионального разработчика), то без сомнения можно утверждать что ACCESS корпорации Microsoft это лучшее средства для решения задач любой сложности.

Цель данного реферата изучить основные этапы разработки базы данных, программу Microsoft Access и правила нормализации.

Задачи реферата:

— изучить основные этапы разработки базы данных;

— охарактеризовать базы данных в Microsoft Access;

— рассмотреть правила нормализации.

Заключение:

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

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

Microsoft Access, обладая всеми чертами классической СУБД, предоставляет и дополнительные возможности. Access — это не только мощная, гибкая и простая в использовании СУБД, но и система для разработки работающих с базами данных приложений. С помощью Access вы можете создать приложение, работающее в среде Windows и полностью соответствующее вашим потребностям по управлению данными. Используя запросы, вы можете выбирать и обрабатывать хранящуюся в таблицах информацию. Можно создавать формы для ввода, просмотра и обновления данных, а также использовать Access для создания как простых так и сложных отчетов. Формы и отчеты «наследуют» свойства базовой таблицы или запроса, так что в большинстве случаев вы указываете форматы, условия на значения и некоторые другие характеристики данных только один раз. К числу наиболее мощных средств Access относятся средства разработки объектов — Мастера, которые можно использовать для создания таблиц, запросов различных типов форм и отчетов, просто выбрав с помощью мыши нужные опции.

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

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

Фрагмент текста работы:

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

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

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

Можно выделить пять основных этапов проектирования БД:

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

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

3. Выбор СУБД.

4. Даталогическое проектирование.

5. Физическое проектирование.

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

В общем случае выделяют два подхода к выбору состава и структуры предметной области:

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

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

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

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

Инфологическое проектирование – частично формализованное описание объектов предметной области в терминах некоторой семантической модели.

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

На сегодняшний день наиболее широкое распространение получила модель Чена «Сущность-связь» (Entity Relationship), она стала фактическим стандартом в инфологическом моделировании, и получило название ER – модель.

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

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

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

· Описание концептуальной схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности БД.