рефераты скачать
 
Главная | Карта сайта
рефераты скачать
РАЗДЕЛЫ

рефераты скачать
ПАРТНЕРЫ

рефераты скачать
АЛФАВИТ
... А Б В Г Д Е Ж З И К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я

рефераты скачать
ПОИСК
Введите фамилию автора:


Дипломная работа: Разработка базы данных

В некоторых реализация СУБД рассматривается еще одна стратегия поддержания ссылочной целостности:

·  IGNORE (ИГНОРИРОВАТЬ) - выполнять операции, не обращая внимания на нарушения ссылочной целостности.

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

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

В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:

·  первая нормальная форма (1NF);

·  вторая нормальная форма (2NF);

·  третья нормальная форма (3NF);

·  нормальная форма Бойса-Кодда (BCNF);

·  четвертая нормальная форма (4NF);

·  пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Основные свойства нормальных форм:

·  каждая следующая нормальная форма в некотором смысле лучше предыдущей;

·  при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

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

В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.

Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.

Функциональная зависимость R.X (r) R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X (r) R.Z и R.Z (r) R.Y и отсутствует функциональная зависимость R.Z --> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)

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

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

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

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

Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно завис

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

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

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

Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом.

В отношении R (A, B, C) существует многозначная зависимость R.A (r) (r) R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.

Легко показать, что в общем случае в отношении R (A, B, C) существует многозначная зависимость R.A (r) (r) R.B в том и только в том случае, когда существует многозначная зависимость R.A (r) (r) R.C.

Теорема Фейджина. Отношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и только в том случае, когда существует MVD A (r) (r) B | C.

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

Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A (r) (r) B все остальные атрибуты R функционально зависят от A.

Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.

Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения - PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.

Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется. Заметим, что зависимость соединения является обобщением как многозначной зависимости, так и функциональной зависимости.


4. РАЗРАБОТКА БАЗЫ ДАННЫХ

4.1 Предметная область базы данных

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

Анализ запросов на литературу показывает, что для поиска подходящих источников (по тематике, названию, автору) и отбора нужного следует выделить следующие атрибуты источников литературы:

1)  автор (фамилия и имена (инициалы) или псевдоним каждого автора источника литературы);

2)  название (заглавие) источника литературы;

3)  язык, на котором написан источник;

4)  список тем (разделов), с которыми связан данный источник литературы.

К объектам и атрибутам, позволяющим охарактеризовать место расположение файлов источников, можно отнести:

1)  полное файловое имя (путь и имя файла) архива источника литературы;

2)  название основного (первого) файла источника литературы.

4.2 Построение инфологической модели

Анализ определенных выше объектов и атрибутов позволяет выделить сущности проектируемой базы данных и, приняв решение о создании реляционной базы данных, построить ее инфологическую модель на языке "Таблицы-связи" (рис. 4.1). Для того, чтобы БД сохраняла целостность при любых операциях над ней (вставка, удаление, изменение кортежей), все отношения в ней нормализованы (БД приведена к третей нормальной форме).

Выделены следующие сущности:

1)  “Авторы” (“Код автора”, “Автор”) – эта сущность отводится для хранения сведений об авторах литературных источников. Так как фамилия и имена (инициалы) автора (группы авторов) могут быть достаточно громоздкими и будут многократно встречаться в разных источниках, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Код автора", который будет автоматически наращиваться на единицу при вводе в базу данных нового автора. Самой же информации об авторе соответствует атрибут “Автор”.

2)  “Заглавия” (“Код заглавия”, “Заглавие”). Выделение этой сущности позволит сократить объем данных и снизить вероятность возникновения противоречивости. Как и сущность “Авторы”, данная сущность характеризуется двумя атрибутами – целочисленным "Код заглавия", который будет автоматически наращиваться на единицу при вводе в базу данных нового заглавия и “Заглавие”, непосредственно отражающий заглавие источника литературы.

3)  “Языки” (“Код языка”, “Язык”) – эта сущность отражает информацию об языке, на котором написан источник литературы. Данная сущность также включает в себя два атрибута: “Код языка” – целочисленный автоматически увеличивающийся и “Язык” –название языка источника литературы.

4)  “Книги” (“Код книги”, “Код автора”, “Код заглавия”, “Код языка”, “Темы”, “Архив”, “Файл”) – эта сущность отражает информацию о конкретных источниках литературы.


Рисунок 4.1 Инфологическая модель БД

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

Для физической реализации БД использовалась СУБД InterBase версии 6.0. Эта СУБД была выбрана по ряду причин:

1)  поддержка данной СУБД реляционных и распределённых баз данных;

2)  высокая надёжность;

3)  наличие реализации СУБД для ОС Linux (кроссплатформенность продукта);

4)  соответствие встроенного языка SQL стандарту ANSI SQL-92;

5)  малые требования к дисковому пространству и памяти;

6)  свободное распространение СУБД в открытых кодах.

Полный листинг кода создания БД на языке SQL (встроенный в InterBase) находится в приложении 20. Поэтапно рассмотрим физическую реализацию БД. Зададим 3 диалект БД и русскую кодировку символов WIN1251. Создаём пустую БД от лица суперпользователя SYSDBA со стандартным паролем “masterkey”. Размер страница БД установлен равным размеру кластера в файловой системе NTFS 4048 байт. Для удаления из строк пробелов и преобразования строк к верхнему регистру были декларированы внешние функции Upper и Trim. Они реализованы на языке программирования Delphi и физически расположены в динамически связуемой библиотеке (DLL) Str.dll.

Каждая из полученных сущностей должна быть представлена базовой таблицей:

Таблица Authors – информация об авторах источников, состоящая из следующих полей:

1)  NumAut – числовое автоинкрементное поле, содержащее номер автора и являющееся ключевым полем отношения;

2)  Author – строковое поле, содержащее фамилию и инициалы автора (группы авторов), являющееся уникальным.

Таблица Titles – информация об названиях источников состоящая из следующих полей:

1)  NumTit – числовое автоинкрементное поле, содержащее номер заглавия и являющееся ключевым полем отношения;

2)  Titles – строковое поле, содержащее название источника и являющееся уникальным.

Таблица Languages – языки источников, состоящая из следующих полей:

1)  NumLan – числовое автоинкрементное поле, содержащее номер языка и являющееся ключевым полем отношения;

2)  Language - строковое поле, содержащее язык источника и являющееся уникальным полем.

Таблица Books – информация об источниках литературы, состоящая из следующих полей:

1)  NumBook – числовое автоинкрементное поле, содержащее номер книги и являющееся ключевым полем отношения;

2)  NumAut – числовое поле, содержащее код (номер) автора в таблице Authors;

3)  NumTit - числовое поле, содержащее код (номер) названия в таблице Titles;

4)  NumLan - числовое поле, содержащее код (номер) языка в таблице Languages;

5)  Sections – текстовое (мемо) поле, содержащее список тем, связанных с источником;

6)  Atchive – строковое поле, содержащее полное файловое имя архива источника;

7)  MainFile – строковое поле, содержащее имя главного файла источника.

Таблица Books связана с таблицами Authors, Titles, Languages типом связи “один-ко-многим” посредством внешних ключей NumAut, NumTit и NumLan.

Создаём таблицу Authors с непустыми полями NumAut типа INTEGER и Author типа VARCHAR длиной 50 символов, поле NumAut является первичным ключом, а Author уникальным полем. Аналагично создаём таблицу Titles с непустыми полями NumTit типа INTEGER и Title типа VARCHAR длиной 200 символов, поле NumTit является первичным ключом, а Title уникальным полем. Также создаём таблицу Languages с непустыми полями NumLan типа INTEGER и Language типа VARCHAR длиной 20 символов, поле NumLan является первичным ключом, а Language уникальным полем. Наконец создаём таблицу Books с полями NumLan – непустое поле типа INTEGER, являющееся первичным ключом таблицы; NumAut - поле типа INTEGER; NumTit - поле типа INTEGER; NumLan - поле типа SMALLINT; Sections – поле типа BLOB подтипа TEXT; Archive – непустое поле типа VARCHAR длиной 32765 байт и MainFile – непустое поле типа VARCHAR длиной 255 байт. Также на таблицу Books накладываются ограничения, посредством задания внешних ключей NumAut, NumTit и NumLan, которые связаны с аналогичными полями в таблицах Authors, Titles и Languages.

Для того, чтобы поля таблиц NumBook, NumAut, NumTit и NumLan автоматически увеличивались при добавлении новой записи необходимо задать создать генераторы. Назовём их GenBook, GenAut, GenTit и GenLan для соответственно. Для их увеличения созданы триггеры InsBook, InsAut, InsTit и InsLan, которые активизируются перед занесением новой записи в соответствующую таблицу и выполняют увеличение генераторов на единицу посредством вызова встроенной процедуры GEN_ID.

Создадим представление (VIEW), которое состоит из следующих полей Number, Author, Title, Language, Sections, Archive и File. Они являются результатом выборки следующих полей таблиц Books.NumBook, Authors.Author, Titles.Title, Languages.Language, Books.Sections, Books.Archive, Books.MainFile, при условии

Books.NumAut=Authors.NumAut AND

Books.NumTit=Titles.NumTit AND

Books.NumLan=Languages.NumLan.

Это представление предназначено для скрытия реальной структуры БД от пользователя и облегчения использования БД прикладными программистами.

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

·  DeleteAll – очистка всей БД (удаление всех записей во всех таблицах) и обнуление генераторов;

·  DeleteBook – удаление заданного источника;

·  InsertBook – вставка нового источника;

·  SearchBook – поиск источника по заданным атрибутам с учётом регистра символов;

·  SearchUpBook - поиск источника по заданным атрибутам без учёта регистра символов;

·  UpdateAuthor – изменение автора источника;

·  UpdateBook – изменение атрибутов источника;

·  UpdateTilte – изменение названия источника;

·  UpdateLanguage – изменение языка источника;

·  IsWriter – проверка прав пользователя на изменение БД.

Для управления безопасностью БД созданы три роли:

·  Admin – имеет права на любые действия с БД (чтение, изменение структуры и данных);

·  Writer – имеет права на чтение и изменение данных БД, но не имеет прав на изменение структуры БД;

·  Reader – имеет права только на чтение данных БД.

Эти роли, исходя из выше сказанного, наделены соответствующими правами на соответствующие таблицы и хранимые процедуры.


5. РАЗРАБОТКА ПРИЛОЖЕНИЯ-КЛИЕНТА

5.1 Обоснование выбора среды программирования

Разработка клиентского приложения осуществлялось на языке Delphi (ранее Object Pascal) в среде программирования Borland Delphi 7.0 Enterprise Edition.

Сформулируем основные критерии, по которым производился выбор среды программирования для создания приложения.

1) Создание максимально возможного удобства в работе. Для этого программа должна иметь удобный и современный интерфейс пользователя.

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

3) Поддержка длинных имен файлов.

4) Минимальные затраты на разработку модуля.

5) Максимальная переносимость исходного кода программы для платформы Linux.

В ходе последующего анализа имеющихся средств программирования на основании перечисленных критериев был выбран вариант написания данного модуля с использованием системы визуального программирования Borland Delphi 7.0. Данное заключение основывалось на следующем.

Среда визуального программирования Delphi 7.0 работает в среде Windows 9x/NT/2000/XP и предоставляет программисту возможность реализации всех достоинств графического интерфейса этой системы. Так как подавляющее большинство пользователей персональных компьютеров работают сегодня в среде операционных систем семейства Windows, то этот интерфейс является для них наиболее привычным и удобным.

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

Так как Delphi 7.0 является средой программирования для Windows, то, как и сама операционная система Delphi поддерживает длинные имена файлов и папок.

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

Среда визуального программирования Delphi 7.0 является мощным средством для быстрой и качественной разработки программ для операционной системы Windows 95. Имеющаяся библиотека визуальных компонентов позволяет создать интерфейс с пользователем за считанные минуты. Объектно-ориентированный язык Object Pascal, положенный в основу Delphi, является расширением языков Turbo Pascal и Borland Pascal фирмы Borland и нашел в себе отражение новых веяний в программировании. Компонентный принцип, используемый в Delphi, позволяет создавать полноценные Windows-приложения, написав минимальное количество строк кода. Delphi представляет собой открытую систему, позволяя добавлять свои компоненты в систему, модифицировать уже имеющиеся стандартные компоненты благодаря тому, что предоставлены их исходные тексты. Благодаря всему этому разработка программ в среде Delphi становится легкой и приятной.

Также, вследствие того, что большинство компонентов Delphi 7.0 идентично компонентам Kylix, то переход под платформу Linux будет занимать минимально возможное время.

Таким образом, выбранная платформа, как было показано выше, удовлетворяет поставленным требованиям, поэтому выбор был остановлен на данной системе программирования.

5.2 Средства Delphi для работы с базами данных

Хотя Delphi не имеет своего формата таблиц БД, она тем не мене обеспечивает мощную поддержку различных СУБД – как локальных (например, dBase или Paradox), так и промышленных (например, Sybase или InterBase). Средства Delphi для работы с БД можно разделить на три вида:

1) инструментальные средства;

2) компоненты.

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

Для операций с БД система Delphi предлагает следующий набор инструментальных средств.

1)  Borland Database Engine (BDE) – процессор баз данных, который представляет собой набор динамических библиотек и драйверов, предназначенных для организации доступа к БД из Delphi-приложений. BDE является центральным звеном при организации доступа к данным.

2)  BDE Administrator – утилита для настройки различных параметров BDE.

3)  Database Desktop – программа создания и редактирования таблиц, SQL- запросов и запросов QBE.

4)  SQL Explorer – проводник БД, позволяющий просматривать и редактировать БД и словари данных.

5)  SQL Builder – программа визуального конструирования SQL-запросов.

6)  SQL Monitor – программа отслеживания порядка выполнения SQL-запросов к удалённым БД.

7)  Data Pump – программа для переноса данных между БД.

8)  IBConsole – программа для управления удалёнными БД.

9)  InterBase Sever Manager – программа для запуска сервера InterBase.

10)  SQL Links – драйверы для доступа к удалённым промышленным СУБД, таким как Microsoft SQL Server или Oracle. К промышленному серверу InterBase, который поставляется совместно с Delphi и является для него родным, доступ также можно организовать напрямую через BDE, не используя драйверы SQL-Links.

11)  dbExpress – набор драйверов для доступа к базам данных SQL с помощью таких компонентов, как SQLConnection, SQLDataSet, SQLQuery, SQLStoredProc и SQLTable. dbExpress включает в свой состав следующие драйверы:

·  InterBase – DBEXPINT.DLL;

·  DB2 – DBEXPDB2.DLL;

·  Oracle – DBEXPORA.DLL;

·  MySQL – DBEXPMYS.DLL.

12)  InterBase Server – клиентская и серверная часть SQL.

Компоненты, предназначенные для работы с БД, находятся на страницах Data Access, Data Control, dbExpress, BDE, ADO, Decision Cube, QReport и InterBase палитры компонентов. Некоторые компоненты предназначены специально для работы с удалёнными БД в архитектуре “клиент-сервер”.


5.3 Реализация приложения

5.3.1 Общее описание форм и модулей

Для реализации интерфейса с базой данных был выбран набор компонентов прямого доступа к серверу InterBase. Этот выбор имеет ряд преимуществ по сравнению с другими группами компонентов. Основным преимуществом является то, что данный набор компонент предназначен специально для доступа к СУБД InterBase и он позволяет более произвести более тонкие настройки приложения. Нет необходимости установки совместно с программой BDE или копирования библиотек драйверов для доступа к серверу, что способствует экономии дискового пространства и времени при установке. Также компоненты InterBase в Delphi аналогичны компонентам InterBase в Kylix, что существенно снижает затраты при смене платформы приложения.

Листинг файла проекта приложения (Lib.dpr) расположен в приложении Б.

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

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

2.  DataModule1 (см. приложение А, рис. А.2), наследник типа TDataModule – простой модуль данных, являющийся контейнером для невизуальных компонентов, реализующих взаимодействие приложения с БД. Данной форме соответствует модуль DBUnit (см. приложение Г).

3.  EditForm (см. приложение А, рис. А.3), наследник типа TForm – диалоговое окно редактирования (добавления/изменения) записей БД. Форме соответствует модуль Edit (см. приложение Д).

4.  DeleteForm (см. приложение А, рис. А.4), наследник типа TForm – диалоговое окно подтверждения удаления текущей записи БД. Форме соответствует модуль Delete (см. приложение Е).

5.  FilterForm (см. приложение А, рис. А.5), наследник типа TForm – диалоговое окно задания фильтра БД. Данной форме соответствует модуль Filter (см. приложение Ж).

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10


рефераты скачать
НОВОСТИ рефераты скачать
рефераты скачать
ВХОД рефераты скачать
Логин:
Пароль:
регистрация
забыли пароль?

рефераты скачать    
рефераты скачать
ТЕГИ рефераты скачать

Рефераты бесплатно, реферат бесплатно, рефераты на тему, сочинения, курсовые работы, реферат, доклады, рефераты, рефераты скачать, курсовые, дипломы, научные работы и многое другое.


Copyright © 2012 г.
При использовании материалов - ссылка на сайт обязательна.