Разработка базы данных

МОСКОВСКИЙ  ГОСУДАРСТВЕННЫЙ

 ГОРНЫЙ  УНИВЕРСИТЕТ 
 
 
 
 

Реферат

по дисциплине «Базы данных».

Тема: «Разработка  проекта базы данных». 
 
 
 
 

                     Выполнила:

                     студентка группы САПР-1В-07

                     Варнакова Е. Е.

                     Проверил:

                     Рябов Л.П. 
 
 
 

Москва

2010г.

«Разработка проекта базы данных»

1. Основные этапы разработки БД. Постановка задачи, последовательность выполнения частей, анализ данных, определение структуры данных, разработка макета решения задачи, тестирование.
2. Взаимодействие задач.
3. Основные принципы проектирования БД. Эффективное использование памяти. Нормализация. Уникальность полей, первичные ключи, функциональная зависимость, независимость полей. Четыре правила нормализации таблиц.
4. Эффективность связей. Создание связей между таблицами.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Введение.

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

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

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

Кроме выбора архитектуры, необходимо определиться с инструментарием. В зависимости от класса систем, от требований по доступности и по совокупной стоимости владения, может  быть выбрана СУБД Oracle, MS SQL Server, PostgreSQL, MySQL или другая, более подходящая в данном конкретном случае.

Основные  этапы разработки БД.

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

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

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

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

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

Разработка  базы данных разбивается  на следующие основные этапы.

1.Определение цели создания базы данных. 
На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать. То есть нуж-но определить основные темы таблиц базы данных и информацию, которую будут содержать поля таблиц. 
База данных должна отвечать требованиям тех, кто будет непосредственно с ней работать. Для этого нужно определить темы, которые должна покрывать база данных, отчеты, которые она должна выдавать, проанализировать формы, которые в настоящий момент используются для записи данных, сравнить создаваемую базу данных с хорошо спроектированной, подоб-ной ей базой. 
 
2. Определение таблиц, которые должна содержать база данных. 
Одним из наиболее сложных этапов в процессе проектирования базы данных является разра-ботка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы. 
При проектировании таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При проектировке таблиц рекомендуется руково-дствоваться следующими основными принципами: 
• Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. 
Когда определенная информация храниться только в одной таблице, то и изменять ее при-дется только в одном месте. Это делает работу более эффективной, а также исключает воз-можность несовпадения информации в разных таблицах.  
• Каждая таблица должна содержать информацию только на одну тему. 
Сведения на каждую тему обрабатываются намного легче, если содержатся они в независи-мых друг от друга таблицах. Например, адреса и заказы клиентов хранятся в разных табли-цах для того, чтобы при удалении заказа информация о клиенте осталась в базе данных. 
 
3. Определение необходимых в таблице полей. 
Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содер-жит отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить: 
• Каждое поле должно быть связано с темой таблицы. 
• Не рекомендуется включать в таблицу данные, являющиеся результатом выражения. 
• В таблице должна присутствовать вся необходимая информация. 
• Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «ФИО»). 
 
4. Задание первичного ключа для каждой таблицы. 
С тем чтобы Microsoft Access мог связать данные из разных таблиц, например, данные о кли-енте и его заказы, каждая таблица должна содержать поле или набор полей, которые будут однозначно идентифицировать каждую запись в таблице. Такое поле или набор полей назы-вают первичным ключом. 
 
5. Определение связей между таблицами. 
После распределения данных по таблицам и определения ключевых полей необходимо определить связи между таблицами. Для этого надо служит кнопка Схема данных. Связи нужны для того, чтобы обеспечить синхронное изменение одноименных полей в разных таблицах. Самый распространенный вид связи – «один-ко-многим». 
 
6. Обновление структуры базы данных. 
После проектирования таблиц, полей и связей необходимо еще раз просмотреть структуру базы данных и выявить возможные недочеты. Желательно это сделать на данном этапе, пока таблицы не заполнены данными. 
Для проверки необходимо ввести несколько записей в каждую таблицу и посмотреть, отве-чает ли база данных поставленным требованиям. Рекомендуется также создать черновые вы-ходные формы и отчеты и проверить, выдают ли они требуемую информацию. Кроме того необходимо исключить из таблиц все возможные повторения данных. 

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

Основные  принципы проектирования БД.

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

  Теория  нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть  нормальных форм, пять из которых так  и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.

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

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

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

Первая  нормальная форма

  Первая  нормальная форма:

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

Вторая  нормальная форма

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

Третья  нормальная форма

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

Нормальная  форма Бойса-Кодда

  Нормальная  форма Бойса-Кодда требует, чтобы  в таблице был только один потенциальный  первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.

Четвертая нормальная форма

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

Пятая нормальная форма

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

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

Краткие итоги. Зачем нужна  нормализация.

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

Уникальность  полей.

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

Уникальное  поле - это поле, значения в котором не могут повторяться.

Поле Фамилия в таблице Автор вполне может содержать нескольких Ивановых, Петровых или Сидоровых, точно также как поле Имя может пестрить различными Аланами, Эдуардами и Робертами. Это означает, что эти поля не являются уникальными и поэтому их нельзя использовать для связи между таблицами. ПолеНазвание - более удачный кандидат на почетное звание уникального поля, но не тут то было... Многие современные авторы очень любят называть свои произведения в точности так, как это делали Пушкин, Лермонтов или Толстой. Что же тогда остается делать?

Выход всегда есть! Если ни одно поле в Вашей  таблице не приемлемо как уникальное, то его можно создать искусственно. Например, введя в таблицу шифр записи. Это могут быть буквы (например, первые буквы слов названия кники), цифры или их комбинация, но самое главное - они не будут повторяться, а значит, станут уникальными для каждой записи в таблице.

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