Проектирование баз данных методом нормализации

Министерство образования и культуры РФ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧЕРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«УССУРИЙСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДАГОГИЧЕСКИЙ ИНСТИТУТ»

Кафедра информатики и вычислительной техники

На правах рукописи

Крюков Роман Сергеевич

Проектирование баз данных методом нормализации

Дипломная работа

Специальность 050202 информатика с доп. Специальностью 050203 физика

Руководитель –

ст. преподаватель

Кляченко И.Г.

___________________

подпись

Работа допущена к защите              

«___»_______________________2011г.

  ___________________________

Заведующая кафедрой информатики и

Вычислительной техники, к.ф.-м.н., доцент

Горностаева Т.Н.

Работа защищена

«___»_______________________2011г.

Оценка_________________________

Уссурийск 2011

Оглавление

ВВЕДЕНИЕ

Глава I  Проектирование базы данных

Основные понятия Баз данных

Архитектура Базы Данных

Проектирование базы данных

Глава II  Нормализация

Принципы нормализации

Теорема Фейджина

Глава III Создание структуры БД «Классный журнал» методом нормализации

Описание предметной области

Создание структуры БД «Классный журнал» методом нормализации.

Создание приложения для работы с базой данных

TTable и TQuery

Приложение

Заключение

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

ВВЕДЕНИЕ

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

История развития компьютерной техники – это история непрерывного движения от языка и уровня коммуникации машины к уровню пользователя. Если первые машины требовали от пользователя оформления того, что ему нужно (то есть написания программ), в машинных кодах, то языки программирования четвертого уровня (4GLs) позволяли конечным пользователям, не являющимся профессиональными программистами, получать доступ к информации без детального описания каждого шага, но только с встроенными предопределенными типами данных – например, таблицами.

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

В связи с этим тема моей дипломной работы является актуальной.

Цель моей дипломной работы: Создание структуры базы данных на примере «Школьного журнала» с использованием метода нормализации.

Задачи:

      Изучение литературы по теме дипломной работы

      Изучение принципов нормализации

      Изучение предметной области БД

      Создание концептуальной модели

      Создание приложения для работы с БД

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

В I главе рассматривается понятия базы данных, архитектура базы данных и проектирование.

Во II главе рассматривается понятие нормализации, а так же ее принципы.

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

Глава I Проектирование базы данных

Основные понятия Баз данных

Развития вычислительной техники осуществлялось по двум основным направлениям:

      применение вычислительной техники для выполнения численных расчетов;

      использование средств вычислительной техники в информационных системах.

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

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

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

Существуют 4 основные модели данных – списки (плоские таблицы), реляционные базы данных, иерархические и сетевые структуры.

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

Архитектура Базы Данных

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

В составе BDE поставляются стандартные драйверы, обеспечивающие доступ к СУБД Paradox, dBASE, FoxPro и текстовым файлам. Локальные драйверы (рис.1) устанавливаются автоматически совместно с ядром процессора. Один из них можно выбрать в качестве стандартного драйвера, который имеет дополнительные настройки, влияющие на функционирование процессора БД.

Рис 1  
Основная работа с BDE производится посредством внешнего интерфейса IDAPI (IDAPI32.DLL). Формат данных выбирается в псевдониме (alias) соединения, и в принципе дальше работа с разными форматами ничем не отличается. В том числе и неважно, как работает приложение с BDE - через компоненты VCL DB, которые используют функции BDE, или напрямую (все равно компоненты используют те же функции BDE).

Дальше функции IDAPI транслируют вызовы в функции соответствующего драйвера. Если это драйвер локального формата (dBase, Paradox, FoxPro), то драйвер формата сам работает с соответствующими файлами (таблицами и индексами). Если это SQL Link, то вызовы транслируются в вызовы функций API клиентской части конкретного SQL-сервера. Для каждого сервера SQL Link свой. IDAPTOR (соединитель с ODBC) и интерфейс к DAO работает точно также как и SQL Link, т.е. просто транслирует вызовы BDE в вызовы ODBC или DAO, непосредственно к формату не имея никакого отношения.

Если посмотреть на файлы BDE, то можно подробно рассмотреть его составные части.

      Администратор системных ресурсов управляет процессом подключения к данным — при необходимости устанавливает нужные драйверы, а при завершении работы автоматически освобождает занятые ресурсы. Поэтому BDE всегда использует ровно столько ресурсов, сколько необходимо.

      Система обработки запросов обеспечивает выполнение запросов SQL или QBE от приложения к любым базам данных, для которых установлен драйвер, даже если сама СУБД не поддерживает прямое использование запросов SQL.

      Система сортировки является запатентованной технологией и обеспечивает очень быстрый поиск по запросам SQL и через стандартные драйверы аля Paradox и dBASE.

      Система пакетной обработки представляет собой механизм преобразования данных из одного формата в другой при выполнении операций над целыми таблицами. Эта система использована в качестве основы для компонента TBatcMove и утилиты DataPump (автоматического переноса структур данных между базами данных), входящей в стандартную поставку BDE.

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

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

      Транслятор данных обеспечивает преобразование форматов данных для различных типов БД.

      Кэш BLOB используется для ускорения работы с данными в формате BLOB.

      SQL-генератор транслирует запросы в формате QBE в запросы SQL.

      Система реструктуризации обеспечивает преобразование наборов данных в таблицы Paradox или dBASE.

      Система поддержки драйверов SQL повышает эффективность механизма поиска при выполнении запросов SQL.

      Таблицы в памяти. Этот механизм позволяет создавать таблицы непосредственно в оперативной памяти. Используется для ускорения обработки больших массивов данных, сортировки, преобразования форматов данных.

      Связанные курсоры обеспечивают низкоуровневое выполнение межтабличных соединений. Позволяют разработчику не задумываться над реализацией подобных связей при работе на уровне VCL — для этого достаточно установить значения нескольких свойств.

      Менеджер конфигурации обеспечивает разработчику доступ к информации о конфигурации драйверов.

      Таким образом, при установке BDE "лишние" файлы можно без проблем выкинуть.

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

Отдельное место в архитектуре BDE и среди упомянутых файлов занимают Local SQL и QBE Engine. Эти механизмы запросов будут рассмотрены чуть дальше.

Проектирование базы данных

При разработке БД можно выделить следующие этапы работы:

I этап.

Постановка задачи:

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

II этап.

Анализ объекта:

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

III этап.

Синтез модели:

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

IV этап.

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

      с использованием форм.

      без использования форм.

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

V этап.

Синтез компьютерной модели объекта:

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

Стадия 1 Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2 Создание исходной таблицы или таблиц.

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

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

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

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

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

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

Стадия 3 Создание экранных форм.

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

Стадия 4 Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап.

Работа с созданной базой данных:

Работа с БД включает в себя следующие действия:

      поиск необходимых сведений;

      сортировка данных;

      отбор данных;

      вывод на печать;

      изменение и дополнение данных.

Формализация реляционной модели

Основные определения:

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

Теоретической основой этой модели стала теория отношений, основу которой заложили два логика — американец Чарльз Содерс Пирс (1839-1914) и немец Эрнст Шредер (1841-1902). В руководствах по теории отношений было показано, что множество отношений замкнуто относительно некоторых специальных операций, то есть образует вместе с этими операциями абстрактную алгебру. Это важнейшее свойство отношений было использовано в реляционной модели для разработки языка манипулирования данными, связанного с исходной алгеброй. Американский математик Э. Ф. Кодд в 1970 году впервые сформулировал основные понятия и ограничения реляционной модели, ограничив набор операций в ней семью основными и одной дополнительной операцией. Предложения Кодда были настолько эффективны для систем баз данных, что за эту модель он был удостоен престижной премии Тьюринга в области теоретических основ вычислительной техники.

Основной структурой данных в модели является отношение, именно поэтому модель получила название реляционной (от английского relation — отношение).

N-арным отношением R называют, подмножество декартова произведения Dx, D2x ... Dnx множеств D1, D2, ..., Dn (n > 1), необязательно различных. Исходные множества D1, D2, ..., Dn называют в модели доменами.

R D1x, D2x...Dxn

где D1, D2x ... Dnx— полное декартово произведение.

Полное декартово произведение — это набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется из своего домена. Например, имеем три домена: D1 содержит три фамилии, D2 — набор из двух учебных дисциплин и D3 — набор из трех оценок. Допустим, содержимое доменов следующее:

D1 = (Иванов, Крылов, Степанов)

D2 = (Теория алгоритмов, Базы данных}

D3 = (3, 4, 5)

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

<Иванов. Теория алгоритмов. 3>: <Иванов. Теория алгоритмов. 4>: <Иванов. Теория алгоритмов. 5>; <Крылов. Теория алгоритмов. 3>: <Крылов. Теория алгоритмов. 4>: <Крылов. Теория алгоритмов. 5>; <Степанов. Теория алгоритмов. 3>: <Степанов. Теория алгоритмов. 4>: <Степанов. Теория алгоритмов. 5>; <Иванов, Базы данных. 3>: <Иванов. Базы данных. 4>: <Иванов. Базы данных. 5>; <Крылов. Базы данных. 3>: <Крылов. Базы данных. 4>: <Крылов. Базы данных. 5>; <Степанов. Базы данных. 3>: <Степанов, Базы данных. 4>: <Степанов, Базы данных. 5>;

Отношение R моделирует реальную ситуацию, и оно может содержать, допустим, только 5 строк, которые соответствуют результатам сессии (Крылов экзамен по «Базам данных» еще не сдавал):

<Иванов. Теория алгоритмов. 3>; <Крылов. Теория алгоритмов. 4>; <Степанов. Теория алгоритмов. 5>; <Иванов. Базы данных. 3>; <Степанов. Базы данных. 4>;

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

Данная таблица обладает рядом специфических свойств:

      В таблице нет двух одинаковых строк.

      Таблица имеет столбцы, соответствующие атрибутам отношения.

      Каждый атрибут в отношении имеет уникальное имя.

      Порядок строк в таблице произвольный.

      Вхождение домена в отношение принято называть атрибутом. Строки отношения называются кортежами.

      Количество атрибутов в отношении называется степенью, или рангом, отношения.

Следует заметить, что в отношении не может быть одинаковых кортежей, это следует из математической модели: отношение — это подмножество декартова произведения, а в декартовом произведении все n-ки различны.

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

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

Схемой отношения R называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

SR = (А1, А2, Аn) Аi Di

Если атрибуты принимают значения из одного и того же домена, то они называются Q-сравнимыми, где Q — множество допустимых операций сравнения, заданных для данного домена. Например, если домен содержит числовые данные , то для него допустимы все операции сравнения, тогда Q = {=, <>,>=,<-,<,>}. Однако и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он имеет также полный спектр операций сравнения.

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

SR1 = (A1, A2, ..., An) — схема отношения R1.

SR2 = (Bi1, Bi2,..., Bin) — схема отношения R2 после упорядочения имен атрибутов.

Тогда:

sR1~sR2<=>1. n=m, или 2. Аj,BijDj

Как уже говорилось ранее, реляционная модель представляет базу данных в виде множества взаимосвязанных отношений. В отличие от теоретико-графовых моделей в реляционной модели связи между отношениями поддерживаются неявным образом. Какие же связи между отношениями поддерживаются в реляционной модели? В этой модели, так же как и в остальных, поддерживаются иерархические связи между отношениями. В каждой связи одно отношение может выступать как основное, а другое отношение выступает в роли подчиненного. Это означает, что один кортеж основного отношения может быть связан с несколькими кортежами подчиненного отношения. Для поддержки этих связей оба отношения должны содержать наборы атрибутов, по которым они связаны. В основном отношении это первичный ключ отношения (PRIMARY KEY), который однозначно определяет кортеж основного отношения. В подчиненном отношении для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Однако здесь этот набор атрибутов уже является вторичным ключом, то есть он определяет множество кортежей подчиненного отношения, которые связаны с единственным кортежем основного отношения. Данный набор атрибутов в подчиненном отношении принято называть внешним ключом (FOREIGN KEY).