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

Содержание

Обзор

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

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

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

Приведение к первой нормальной форме

Приведение ко второй нормальной форме

Приведение к третьей нормальной форме

Заключение

4. Обзор

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

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

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

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

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

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

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

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

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

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

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

2. Определить информационныепотребности базы данных.

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

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

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

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

11.

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

13.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· выбор набора символов,соответствующего данной стране

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

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

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

определение проверочных условий.

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

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

· связь “один-к-одному”

· связь “один-ко-многим”

· связь “многие-ко-многим”.

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

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

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

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

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

· данные легко обновлять или удалять

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

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

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

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

· устранение повторяющихся групп(приведение к 1НФ)

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

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

Рассмотрим каждый из этих процессов подробней.

Приведение к первойнормальной форме

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. Приведение к третьейнормальной форме

Третий этап процесса приведения таблиц к нормальной форме состоит в удалениивсех неключевых атрибутов, которые зависят от других неключевых атрибутов.Каждый неключевой атрибут должен быть логически связан с атрибутом(атрибутами), являющимся первичным ключом. Предположим, например, что мыдобавили поля Номер_руководителя и Телефон в таблицу ПРОЕКТ, находящуюся в 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. Заключение

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

еще рефераты

Еще работы по информатике, программированию

Реферат по информатике, программированию

Средства аппаратной поддержки управления памятью в микропроцессорах Intel 80386, 80486 и Pentium

18 Июня 2015

Реферат по информатике, программированию

Особенности коммутаторов локальных сетей

18 Июня 2015

Реферат по информатике, программированию

LAN Server 4.0

18 Июня 2015

Реферат по информатике, программированию

Управление вводом-выводом

18 Июня 2015