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

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


Смотрите также:
Опираются на единый устоявшийся комплекс основных понятий. Рассмотрим эти понятия...
Программа дисциплины «Базы данных»...
Тема «Основные термины и понятия»...
Системы управления базами данных (субд). Функции субд базы данных (БД)...
Методика выполнения работы Введение в базы данных и Microsoft Access База данных (БД)...
Реферат на тему: Access. Базы данных...
Учебная программа по дисциплине базы данных и субд дорохина Т. В., Скуратовская О. Г...
Управление транзакциями в системах баз данных Понятие транзакции...
Гис-технологии в экологии...
Вопросы к государственному меж...
Вопросы к государственному междисциплинарному...
Лекция №1: Стандарты языка sql...



Загрузка...
страницы: 1   2   3   4   5   6
вернуться в начало
скачать
^

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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


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





^ Рис. 0-A: Термины реляционной теории и их соотношение с обработкой данных



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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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


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

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


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


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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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

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

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


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

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

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

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

  • нужно ли делать различие в правах доступа

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


В среде DELPHI для разработки приложений с базой данных применяют технологии BDE, ADO, Informix, InterBase для получения доступа к данным.

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

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

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

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

Например: в альясе Firma1 нужно создать БД Firma1.

  1. Загрузив Дельфи выполняем команду TOOLS – DATABASEDESKTOP.

  2. В раскрывшемся окне выполняем команду TOOLS – ALIAS MANAGER – и нажимаем кнопку NEW, затем в поле «имя альяса» набираем имя «Firma1».

  3. В этом окне есть DRIVERTYPE - список драйверов – выбираем STANDART .

  4. Нажав кнопку BROWSE этого окна указываем путь, куда мы хотим сохранить альяс, по умолчанию сохраняется (C:\ProgramFiles\Borland\Delphi\Project\Firma1), затем заканчиваем работу нажатием ОК.

  5. При этом выводится диалоговое окно сохранения изменений, соглашаемся нажав Yes.

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

Создание новой таблицы БД:

  1. В окне DATABASEDESKTOP выполняем команду File – New – Table.

  2. В появившемся окне указываем тип создаваемой таблицы TableType - Paradox7 - OK.

  3. На следуюшем окне создаем структуру таблицы БД. Для этого заполняем таблицу, указав FieldName - имя поля, Type – тип поля, Size – длину поля, Key – ключевое поле. Здесь имена полей должны набираться на латинском алфавите.

Существуют следующие типы полей:

Alpha – текствовое поле, длина 255 символов.

Number – вещественный тип, от -10307 до +10308.

$(Money) – денежный тип.

Short – короткое целое, от -32768 до +32767

LongInteger – длинное целое, от -2147483648 до +2147483647.

#(BCD) – вещественный тип с повышенной точностью.

Date – тип даты.

Time – тип времени.

@(Timestamp) – тип даты и времени.

Memo – длинный текстовый тип, длина больше 255 символов.

Formatted Memo – форматированный текстовый тип (указывается шрифт – цвет шрифта, стиль, начертание).

Graphic – Графический тип.

OLE (Object Linking and Embedding) – тип информации, который поддерживает механизм внедрения объектов.

Logical – логический тип.

+(Autoinctement) – счетчик, автоматический возрастает на 1.

Binary – бинарный тип произвольной длины.

Ключевое поле должно распологаться первым в таблице и его имя должно начинаться со слова ID, ставится символ * в столбце Key.

  1. В окне структуры еще можно определить дополнительный свойства полей:

  1. Required Field – обязательное поле.

  2. Minimum Value – минимальное значение (для числовых полей).

  3. Maximum Value – максимальное значение (для числовых полей).

  4. Default Value – значение по умолчанию.

  5. Picture – маска ввода.

  1. Для сохранения структуры таблицы БД нужно нажать кнопку Save As, указать имя таблицы (например Client.db), имя альяса (Firma1).

Работа с таблицей БД

Можно использовать вкладку DataAccess, для получения доступа к данным. Поставим компонент Ttable и указываем свойства:

  1. DatabaseName - имя базы данных (Firma1).

  2. TableName – имя таблицы (Client.db).

  3. Active = True, чтобы активизировать записи к использованию.

После проделанных действий устанавливается прямая связь с БД. Но есть возможность получения доступа косвенным путем, через источника данных. Для этого используем компонент DBataSource и указываем свойство DataSet – Table1.


Вопросы для самопроверки:

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

            2. Как определяют информационные потребности базы данных.

            3. Как можно проанализировать объекты реального мира, которые необходимо смоделировать в базе данных.

            4. Как можно поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД

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

            6. Существуют какие правила, которые будут устанавливать и поддерживать целостность данных

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

            8. Как можно установить связи между объектами

            9. Какие виды связи существуют?

            10. Требования к базам данных, а также основные шаги по проектированию баз данных

            11. Вопрос нормализации таблиц и проблемы, связанные с этим процессом


Лекция – 7. Настройка BDE

Цель лекции: рассмотреть вопросы настройки технологий BDE. Основные понятия алиаса, применение системных утилит.


Сущность BDE

Алиасы

Системная информация утилиты настройки BDE (BDECFG)

Установка драйверов ODBC и других драйверов


Ядром баз данных компании Борланд является - Borland Database Engine (BDE), Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). В принципе, сейчас не различают эти два названия (BDE и IDAPI) и считают их синонимами. BDE позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный “ODBC socket”, который позволяет встраивать их в BDE.

Все инструментальные средства баз данных Borland - Paradox, dBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или dBase, “наследуются” BDE, и поэтому этими же особенностями обладает и Delphi.





оставить комментарий
страница5/6
Дата31.03.2012
Размер0,86 Mb.
ТипДокументы, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6
отлично
  1
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

наверх