Учебная работа. Реферат: Основы работы с базами данных Delphi

Учебная работа. Реферат: Основы работы с базами данных Delphi

Содержание

Обзор

Требования к базам данных

Главные концепции реляционных баз данных

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

Приведение к первой обычной форме

Приведение ко 2-ой обычной форме

Приведение к третьей обычной форме

Заключение

1.

1.

1.

2.

3.

4. Обзор

5. В этом уроке описываются базы работы с базами данных. Напомним, что под базой данных понимается некая унифицированная совокупа данных, вместе применяемая персоналом/популяцией группы, компании, региона, страны, мира… Задачка базы данных состоит в хранении всех представляющих Энтузиазм данных в одном либо нескольких местах, при этом таковым методом, который заранее исключает ненадобную избыточность. В отлично спроектированной базе данных избыточность данных исключается, и возможность сохранения противоречивых данных минимизируется. Таковым образом, создание баз данных преследует две главные цели: снизить избыточность данных и повысить их надежность.

Во вводном уроке (номер 1) мы дали короткое, “на пальцах”, истолкование локальных и серверных баз данных и пояснили сущность технологии клиент-сервер. На данном уроке мы разглядим процесс проектирования баз данных, общий для обеих технологий. И только детали его реализации будут различаться в различных архитектурах. сходу оговоримся, что мы будем разглядывать лишь реляционные базы данных: во-1-х, реляционные базы получили наибольшее распространение в мире; во-2-х, они более “продвинуты” в научном плане; а в-3-х, ядро баз данных

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

Актуальный цикл хоть какого программного продукта, в том числе и системы управления базой данных, состоит (по-крупному) из стадий
,
и
.

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

6. Требования к базам данных

Итак, отлично спроектированная база данных:

·

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

·

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

·

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

·

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

Последующие пункты представляют главные шаги проектирования базы данных:

1.

2. Найти информационные потребности базы данных.

3.

4. Проанализировать объекты настоящего мира, которые нужно смоделировать в базе данных. Сформировать из этих объектов сути и свойства этих сущностей (к примеру, для сути “
” чертами могут быть “
”, “
”, “
” и т.п.) и сформировать их перечень.

5.

6. Поставить в соответствие сущностям и чертам — таблицы и столбцы (поля) в нотации избранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).

7.

8. Найти атрибуты, которые неповторимым образом идентифицируют любой объект.

9.

10. Выработать правила, которые будут устанавливать и поддерживать целостность данных.

11.

12. Установить связи меж объектами (таблицами и столбцами), провести нормализацию таблиц.

13.

14. Спланировать вопросцы надежности данных и, по мере необходимости, сохранения секретности инфы.

1.

1.

1. Главные концепции реляционных баз данных

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

. Математически отношение определяется последующим образом. Пусть даны n множеств D1
,D2
,…,Dn
. Тогда R есть отношение
над этими огромными количествами, если R есть огромное количество упорядоченных наборов вида <d1
,d2
,…,dn
>, где d1
— элемент из D1
, d2
— элемент из D2
, …, dn
— элемент из Dn
. При всем этом наборы вида <d1
,d2
,…,dn
> именуются кортежами
, а огромного количества D1
,D2
,…,Dn
— доменами
. Любой кортеж состоит из частей, избираемых из собственных доменов. Эти элементы именуются атрибутами
, а их значения — значениями атрибутов. рис. 0-a представляет нам графическое изображение дела с различных точек зрения.

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

·

· отношение, таблица, файл (для локальных баз данных)

·

· кортеж, строчка, запись

·

· атрибут, столбец, поле.

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

Атрибут (либо набор атрибутов), который быть может применен для конкретной идентификации определенного кортежа (строчки, записи), именуется первичным ключом
. Первичный ключ не должен иметь доп атрибутов. Это означает, что если из первичного ключа исключить случайный атрибут, оставшихся атрибутов будет недостаточно для конкретной идентификации отдельных кортежей. Для убыстрения доступа по первичному ключу во всех системах управления базами данных (СУБД) имеется механизм, именуемый
. Грубо говоря, индекс представляет собой инвертированный древовидный перечень, указывающий на настоящее положение записи для всякого первичного ключа. естественно, в различных СУБД индексы реализованы по-разному (в локальных СУБД — как правило, в виде отдельных файлов), но, принципы их организации схожи.

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

Для поддержания ссылочной целостности данных в почти всех СУБД имеется механизм так именуемых наружных ключей
. Смысл этого механизма заключается в том, что некоему атрибуту (либо группе атрибутов) 1-го дела назначается ссылка на первичный ключ другого дела; тем закрепляются связи подчиненности меж этими отношениями. При всем этом отношение, на первичный ключ которого ссылается наружный ключ другого дела, именуется
, либо основным отношением; а отношение, от
которого исходит ссылка, именуется
, либо подчиненным отношением. Опосля предназначения таковой ссылки СУБД имеет возможность автоматом выслеживать вопросцы “ненарушения“ связей меж отношениями, а конкретно:

·

· если Вы попытаетесь вставить в подчиненную таблицу запись, для наружного ключа которой не существует соответствия в главной таблице (к примеру, там нет еще записи с таковым первичным ключом), СУБД сгенерирует ошибку;

·

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

·

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

Замечание.

Существует два подхода к удалению и изменению записей из главной таблицы:

1.

1.

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

3.

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

·

o

o если в главной таблице удалена запись, то в подчиненной таблице должны быть удалены все записи, ссылающиеся на удаляемую;

o

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

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

1.

1.

1. Шаги проектирования базы данных

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

·

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

·

· какие данные употребляются различными приложениями; сумеют ли Ваши приложения вместе применять какие-либо из этих данных;

· кто будет вводить данные в базу и в которой форме; как нередко будут изменяться данные;

· довольно ли будет для Вашей предметной области одной базы либо Для вас будет нужно несколько баз данных с разными структурами;

· какая информация является более чувствительной к скорости ее извлечения и конфигурации.

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

Формирование концептуальной модели базы данных содержит в себе:

·

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

·

· идентификацию объектов, которые производят эту многофункциональную деятельность, и формирование из их операций последовательности событий, которые посодействуют Для вас идентифицировать все сути и связи меж ними. к примеру, процесс “ведение учета работающих” идентифицирует такие сути как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.

·

· идентификацию черт этих сущностей. К примеру, суть РАБОТНИК может включать такие свойства как Идентификатор Работника, Фамилия, имя, Отчество, Профессия, Заработная плата.

·

· идентификацию взаимосвязей меж сущностями. К примеру, каким образом сути РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ ведут взаимодействие друг с другом? Работник имеет одну профессию (для простоты!) и числится в одном отделе, в то время как в одном отделе может находиться много работников.

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

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

IV.
На четвертом шаге определяются атрибуты, которые неповторимым образом идентифицируют любой объект. Это нужно для того, чтоб система могла получить всякую единичную строчку таблицы. Вы должны найти первичный ключ для всякого из отношений. Если нет способности идентифицировать кортеж при помощи 1-го атрибута, то первичный ключ необходимо создать составным — из нескольких атрибутов. Неплохим примером быть может первичный ключ в таблице работников, состоящий из фамилии, имени и отчества. Первичный ключ гарантирует, что в таблице не будет содержаться 2-ух схожих строк. В почти всех СУБД имеется возможность кроме первичного определять еще ряд неповторимых ключей
. Отличие неповторимого ключа от первичного заключается в том, что неповторимый ключ не является основным идентифицирующим фактором записи и на него не может ссылаться наружный ключ иной таблицы. Его основная задачка — гарантировать неповторимость значения поля.

V.
5-ый шаг подразумевает выработку правил, которые будут устанавливать и поддерживать целостность данных. Будучи определенными, такие правила в клиент-серверных СУБД поддерживаются автоматом — сервером баз данных; в локальных же СУБД их поддержание приходится ложить на пользовательское приложение.

Эти правила включают:

·

· определение типа данных

·

· выбор набора знаков, соответственного данной стране

·

· создание полей, опирающихся на домены

· установка значений по дефлоту

· определение ограничений целостности

определение проверочных критерий.

VI.
На шестом шаге инсталлируются связи меж объектами (таблицами и столбцами) и делается весьма принципиальная операция для исключения избыточности данных — нормализация таблиц.

Любой из разных типов связей должен быть смоделирован в базе данных. Существует несколько типов связей:

·

· связь

·

· связь

·

· связь
.

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

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

Связь “многие-ко-многим” в очевидном виде в реляционных базах данных не поддерживается. Но имеется ряд методов косвенной реализации таковой связи, которые с фуррором возмещают ее отсутствие. один из более всераспространенных методов заключается во внедрении доборной таблицы, строчки которой состоят из наружных ключей, ссылающихся на первичные ключи 2-ух таблиц. к примеру, имеются две таблицы: клиент и ГРУППА_ИНТЕРЕСОВ. один человек быть может включен в разные группы, в то время как группа может соединять воединыжды разных людей. Для реализации таковой связи “многие-ко-многим” вводится доборная таблица, назовем ее КЛИЕНТЫ_В_ГРУППЕ, строчка которой будет иметь два наружных ключа: один будет ссылаться на первичный ключ в таблице клиент, а иной — на первичный ключ в таблице ГРУППА_ИНТЕРЕСОВ. Таковым образом в таблицу КЛИЕНТЫ_В_ГРУППЕ можно записывать хоть какое количество людей и хоть какое количество групп.

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

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

·

· данные просто обновлять либо удалять

·

· исключается возможность рассогласования копий данных

·

· миниатюризируется возможность введения неправильных данных.

процесс нормализации заключается в приведении таблиц в так именуемые
. Существует несколько видов обычных форм: 1-ая обычная форма (1НФ), 2-ая обычная форма (2НФ), 3-я обычная форма (3НФ), обычная форма Бойса-Кодда (НФБК), 4-ая обычная форма (4НФ), 5-ая обычная форма (5НФ). С практической точки зрения, довольно 3-х первых форм — следует учесть время, нужное системе для “соединения” таблиц при отображении их на дисплее. Потому мы ограничимся исследованием процесса приведения отношений к первым трем формам.

Этот процесс включает:

·

· устранение циклических групп (приведение к 1НФ)

·

· удаление отчасти зависимых атрибутов (приведение к 2НФ)

·

· удаление транзитивно зависимых атрибутов (приведение к 3НФ).

Разглядим любой из этих действий подробней.

1. Когда поле в данной записи содержит наиболее 1-го значения для всякого вхождения первичного ключа, такие группы данных именуются
. 1НФ не допускает наличия таковых неоднозначных полей. Разглядим пример базы данных компании, содержащей таблицу ОТДЕЛ со последующими значениями (атрибут, выделенный курсивом, является первичным ключом):

Табл. A: ОТДЕЛ

Заглавие

Управляющий

бюджет

Размещение


100
продаж
000
1000000
Москва

100
продаж
000
1000000
Зеленоград

600
разработок
120
1100000
Тверь

100
продаж
000
1000000
Калуга

Для приведения данной таблицы к 1НФ мы должны убрать атрибут (поле) Размещение из таблицы ОТДЕЛ и сделать новейшую таблицу РАСПОЛОЖЕНИЕ_ОТДЕЛОВ, в какой найти первичный ключ, являющийся композицией номера отдела и его расположения (Номер_отдела+Размещение — см. табл. b). сейчас для всякого расположения отдела есть разные строчки; тем мы убрали повторяющиеся группы.

Табл. B: РАСПОЛОЖЕНИЕ_ОТДЕЛОВ

100
Москва

100
Зеленоград

600
Тверь

100
Калуга

2.

3. Последующий принципиальный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов, которые зависят лишь от части первичного ключа. Такие атрибуты именуются
. Неключевые атрибуты заключают внутри себя информацию о данной сути предметной области, но не идентифицируют ее неповторимым образом. к примеру, представим, что мы желаем распределить работников по проектам, ведущимся на предприятии. Для этого сделаем таблицу ПРОЕКТ с составным первичным ключом, включающим номер работника и идентификатор проекта (Номер_работника+ИД_проекта, в табл. c выделены курсивом).

Табл. C: ПРОЕКТ

Фамилия

Назв_проекта

Описание_
проекта

Продукт


28
БРЖ
Иванов
Биржа
<blob>
программка

17
ДОК
Петров
Документы
<blob>
программка

06
УПР
Сидоров
Управление
<blob>
адм.меры

В данной таблице возникает последующая неувязка. Атрибуты Назв_проекта, Описание_проекта и Продукт относятся к проекту как сути и, как следует, зависят от атрибута ИД_проекта (являющегося частью первичного ключа), но не от атрибута Номер_работника. Как следует, они являются отчасти зависимыми от составного первичного ключа. То же самое можно сказать и о атрибуте Фамилия, который зависит от атрибута Номер_работника, но не зависит от атрибута ИД_проекта. Для нормализации данной таблицы (приведения ее в 2НФ) удалим из нее атрибуты Номер_работника и Фамилия и сделаем другую таблицу (назовем ее РАБОТНИК_В_ПРОЕКТЕ), которая будет содержать лишь эти два атрибута, и они же будут составлять ее первичный ключ.

4.

3-ий шаг процесса приведения таблиц к обычной форме состоит в удалении всех неключевых атрибутов, которые зависят от остальных неключевых атрибутов. Любой неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом. Представим, к примеру, что мы добавили поля Номер_руководителя и телефон в таблицу ПРОЕКТ, находящуюся в 2НФ (первичным ключом является поле ИД_проекта). Атрибут телефон логически связан с атрибутом Номер_руководителя, неключевым полем, но не с атрибутом ИД_проекта, являющимся первичным ключом (табл. d).

Табл. D: ПРОЕКТ

Номер_
управляющего

телефон

Назв_
проекта

Описание_
проекта

Продукт


БРЖ
02
2-21
Биржа
<blob>
программка

ДОК
12
2-43
Документы
<blob>
программка

УПР
08
2-56
Управление
<blob>
адм.меры

Для нормализации данной таблицы (приведения ее в 3НФ) удалим атрибут телефон, изменим Номер_руководителя на Управляющий и создадим атрибут Управляющий наружным ключом, ссылающимся на атрибут Номер_работника (первичный ключ) в таблице РАБОТНИКИ. Опосля этого таблицы ПРОЕКТ и РАБОТНИКИ будут смотреться последующим образом:

Табл. E: ПРОЕКТ

Управляющий

Назв_
проекта

Описание_
проекта

Продукт


БРЖ
02
Биржа
<blob>
программка

ДОК
12
Документы
<blob>
программка

УПР
08
Управление
<blob>
адм.меры

Табл. F: РАБОТНИКИ

Номер_
работника

Фамилия

имя

Отчество

Номер_
отдела

Код_
профес

телефон

Заработная плата


04
Иванов
Иван
Иванович
100
инж
2-69
500

08
Петров
Петр
Петрович
200
мндж
2-56
1000

23
Сидоров
Иван
Петрович
200
мндж
2-45
800

сейчас, когда мы научились проводить нормализацию таблиц с целью устранения лишнего дублирования данных и группирования инфы в логически связанных единицах, нужно создать ряд замечаний по вопросцам проектирования баз данных. нужно верно осознавать, что разбиение инфы на наиболее маленькие единицы с одной стороны, содействует увеличению надежности и непротиворечивости базы данных, а с иной стороны, понижает ее производительность, потому что требуются доп Издержки процессорного времени (серверного либо машинки юзера) на оборотное “соединение” таблиц при представлении инфы на дисплее. время от времени для заслуги требуемой производительности необходимо создать отход от канонической нормализации, при всем этом ясно осознавая, что нужно обеспечить меры по предотвращению противоречивости в данных. Потому всякое решение о необходимости того либо другого деяния по нормализации можно принимать лишь кропотливо проанализировав предметную область и класс поставленной задачки. Может потребоваться несколько итераций для заслуги состояния, которое будет хотимым компромиссом меж четкостью представления и настоящими способностями техники. Тут уже начинается искусство…

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

· кто будет иметь права (и какие) на внедрение базы данных

· кто будет иметь права на модификацию, вставку и удаление данных

· необходимо ли созодать различие в правах доступа

· каким образом обеспечить общий режим защиты инфы и т.п.

1. Заключение

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

]]>