Банк рефератов содержит более 364 тысяч рефератов, курсовых и дипломных работ, шпаргалок и докладов по различным дисциплинам: истории, психологии, экономике, менеджменту, философии, праву, экологии. А также изложения, сочинения по литературе, отчеты по практике, топики по английскому.
Полнотекстовый поиск
Всего работ:
364150
Теги названий
Разделы
Авиация и космонавтика (304)
Административное право (123)
Арбитражный процесс (23)
Архитектура (113)
Астрология (4)
Астрономия (4814)
Банковское дело (5227)
Безопасность жизнедеятельности (2616)
Биографии (3423)
Биология (4214)
Биология и химия (1518)
Биржевое дело (68)
Ботаника и сельское хоз-во (2836)
Бухгалтерский учет и аудит (8269)
Валютные отношения (50)
Ветеринария (50)
Военная кафедра (762)
ГДЗ (2)
География (5275)
Геодезия (30)
Геология (1222)
Геополитика (43)
Государство и право (20403)
Гражданское право и процесс (465)
Делопроизводство (19)
Деньги и кредит (108)
ЕГЭ (173)
Естествознание (96)
Журналистика (899)
ЗНО (54)
Зоология (34)
Издательское дело и полиграфия (476)
Инвестиции (106)
Иностранный язык (62792)
Информатика (3562)
Информатика, программирование (6444)
Исторические личности (2165)
История (21320)
История техники (766)
Кибернетика (64)
Коммуникации и связь (3145)
Компьютерные науки (60)
Косметология (17)
Краеведение и этнография (588)
Краткое содержание произведений (1000)
Криминалистика (106)
Криминология (48)
Криптология (3)
Кулинария (1167)
Культура и искусство (8485)
Культурология (537)
Литература : зарубежная (2044)
Литература и русский язык (11657)
Логика (532)
Логистика (21)
Маркетинг (7985)
Математика (3721)
Медицина, здоровье (10549)
Медицинские науки (88)
Международное публичное право (58)
Международное частное право (36)
Международные отношения (2257)
Менеджмент (12491)
Металлургия (91)
Москвоведение (797)
Музыка (1338)
Муниципальное право (24)
Налоги, налогообложение (214)
Наука и техника (1141)
Начертательная геометрия (3)
Оккультизм и уфология (8)
Остальные рефераты (21697)
Педагогика (7850)
Политология (3801)
Право (682)
Право, юриспруденция (2881)
Предпринимательство (475)
Прикладные науки (1)
Промышленность, производство (7100)
Психология (8694)
психология, педагогика (4121)
Радиоэлектроника (443)
Реклама (952)
Религия и мифология (2967)
Риторика (23)
Сексология (748)
Социология (4876)
Статистика (95)
Страхование (107)
Строительные науки (7)
Строительство (2004)
Схемотехника (15)
Таможенная система (663)
Теория государства и права (240)
Теория организации (39)
Теплотехника (25)
Технология (624)
Товароведение (16)
Транспорт (2652)
Трудовое право (136)
Туризм (90)
Уголовное право и процесс (406)
Управление (95)
Управленческие науки (24)
Физика (3463)
Физкультура и спорт (4482)
Философия (7216)
Финансовые науки (4592)
Финансы (5386)
Фотография (3)
Химия (2244)
Хозяйственное право (23)
Цифровые устройства (29)
Экологическое право (35)
Экология (4517)
Экономика (20645)
Экономико-математическое моделирование (666)
Экономическая география (119)
Экономическая теория (2573)
Этика (889)
Юриспруденция (288)
Языковедение (148)
Языкознание, филология (1140)

Реферат: Базы данных и их сравнительные характеристики

Название: Базы данных и их сравнительные характеристики
Раздел: Рефераты по коммуникации и связи
Тип: реферат Добавлен 11:52:02 24 июня 2011 Похожие работы
Просмотров: 4069 Комментариев: 1 Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать

РЕФЕРАТ

по дисциплине «Информатика»

на тему «Базы данных и их сравнительные характеристики»

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

В зависимости от архитектуры СУБД делятся на локальные и распределенные СУБД. Все части локальной СУБД размещаются на одном компьютере, а распределенной на нескольких. За несколько десятилетий последовательно появлялись системы (СУБД), основанные на трех базовых моделях данных: иерархической, сетевой и реляционной. Основные определения теории баз знаний и баз данных представлены в таблице 1.

Табл.1. Основные определения

Термин Определение
База данных (БД) Базами данных называют электронные хранилища информации, доступ к которым осуществляется с помощью одного или нескольких компьютеров.
Системы управления базами данных (СУБД) это программные средства для создания, наполнения, обновления и удаления баз данных.
База знаний Базы знаний это хранилища знаний, представленных в формализованном виде.
Система управления базами знаний СУБЗ это программные средства для создания, наполнения, обновления и удаления баз знаний

Виды знаний:

Процедурные

Декларативные

Каузальные

Неточные

Знания, отвечающие на вопрос "Как решать поставленную задачу?"

Знания, не содержащие в явном виде процедуры решения задач.

Знания о причинно-следственных связях между объектами предметной области

Знания отличающиеся неполнотой или противоречивостью.

Парадигмы решения задач

В СУБД

В СУБЗ

Данные + Алгоритм = Программа решения задачи

Знания + Стратегия вывода = Решение проблемы.

Модели знаний

Продукционная

Фреймовая

Семантическая сеть

Знания представленные в формате "ЕСЛИ-ТО"

Знания представленные в виде набора взаимосвязанный фреймов.

Граф, вершины которого соответствуют объектам или понятиям, а дуги определяют отношения между вершинами.

Фрейм

Фрейм прототип

Конкретный фрейм

Структурированное описание объекта предметной области состоящее из наименования объекта (имя фрейма), атрибутов объекта (свойств, характеристик) - слоты фрейма.

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

Это фрейм прототип с конкретными значениями.

Enterprise JavaBeans. Стандарт для создания средствами языка Java пригодных для многократного использования компонентов, из которых формируются прикладные программы. Компоненты Enterprise JavaBeans облегчают разработку программ, обеспечивающих доступ к хранимой в базе данных информации.
Распараллеливание обработки запроса (Intraquery parallelism). Использование нескольких ЦП для обработки одного запроса.
Параллельная обработка запросов (interquery parallelism) подразумевает параллельную обработку нескольких запросов (на разных ЦП).
Уровень изоляции(Isolation level). Установочный параметр БД, определяющий, в какой степени одновременно обратившиеся к базе данных пользователи могут оказывать влияние на работу друг друга. Как правило, используются три уровня изоляции: завершение чтения (read committed), характеризуется большим количеством одновременно обслуживаемых пользователей и низким уровнем изоляции каждого из них); в установленном порядке (serializable), небольшое число одновременно обслуживаемых пользователей, высокая степень изоляции и повторяющееся чтение (repeatable read), сочетание двух первых уровней.
Технология СОМ COM - Component Object Model - Компонентная модель объектов, предложена корпорацией Микрософт.
Технология CORBA CORBA - Common Object Require Broker Architecture - архитектура с брокером требуемых общих объектов, разработана независимой группой OMG.
JDBC (Java Database Connectivity). Интерфейс взаимодействия с базами данных на языке Java. Этот стандарт, разработанный фирмой Sun Microsystems, определяет способы доступа Java-приложений к данным БД.
ODBC (Open Database Connectivity). Открытый интерфейс взаимодействия с базами данных. Предложенный корпорацией Microsoft стандарт, регулирующий доступ Windows -приложений к базам данных. Стандарт ODBC постепенно заменяется спецификацией OLE DB.
OLAP (Online analytical processing). Оперативный анализ данных. Этот метод обработки применяется с целью ускорения обработки запросов и предусматривает предварительный расчет часто запрашиваемых данных (например, сумм или значений счетчика).
OLE DB (Object Linking and Embedding Database). OLE для баз данных. Новый стандарт Microsoft, регулирующий доступ приложений к базам данных. Имеет расширения для серверов OLAP и предусматривает применение специальных средств обработки мультимедийных данных.
Операция соединения(Join). Процесс, позволяющий объединять данные из двух таблиц посредством сопоставления содержимого двух аналогичных столбцов.
SQL (Structured query language). Язык структурированных запросов, язык S0L. Является принятым в отрасли стандартом для выполнения операций вставки, обновления, удаления и выборки данных из реляционных БД.
Хранимая процедура(Stored procedure). Программа, которая выполняется внутри базы данных и может предпринимать сложные действия на основе информации, задаваемой пользователем. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД.
Транзакция(Transaction). Совокупность операций базы данных, выполнение которых не может быть прервано. Для того чтобы изменения, внесенные в БД в ходе выполнения любой из входящих в транзакцию операций, были зафиксированы в базе данных, все операции должны завершиться успешно. Все базы данных, представленные в нашем обзоре, позволяют использовать транзакции, тогда как БД для настольных систем, например Visual dBase фирмы Inprise или Microsoft Access, не предусматривают применения механизма транзакций.
Триггер(Trigger). Программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты

2. Иерархическая модель

Первые иерархические и сетевые СУБД были созданы в начале 60-х годов. Причиной послужила необходимость управления миллионами записей (связанных друг с другом иерархическим образом), например при информационной поддержке лунного проекта Аполлон. Среди реализуемых на практике СУБД этого типа преобладает система IMS (Information Management System компании IBM) (На данный момент это самая распространенная СУБД из всех данного типа). Применяютсяидругиеиерархическиесистемы: TDMS (Time-Shared Date Management System) компании Development Corporation; Mark IV Multi - Access Retrieval System компании Control Data Corporation; System - 2000 разработки SAS-Institute.

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

К ограничения иерархической модели данных можно отнести:

1. Отсутствует явное разделение логических и физических характеристик модели;

2. Для представления неиерархических отношений данных требуются дополнительные манипуляции;

3. Непредвиденные запросы могут требовать реорганизации базы данных.

3. Сетевая модель

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

Сетевая модель данных - это представление данных сетевыми структурами типов записей и связанных отношениями мощности один-к-одному или один-ко-многим. В конце 60-х конференция по языкам систем данных (Conference on Data Systems Languages, CODASYL) поручила подгруппе, названной Database Task Group (DTBG), разработать стандарты систем управления базами данных. На DTBG оказывала сильное влияние архитектура, использованная в одной из самых первых СУБД, Iategrated Data Store (IDS), созданной ранее компанией General Electric.Это привело к тому, что была рекомендована сетевая модель.

Документы Database Task Group (DTBG) (группа для разработки стандартов систем управления базами данных) от 1971 года остается основной формулировкой сетевой модели, на него ссылаются как на модель CODASYL DTBG. Она послужила основой для разработки сетевых систем управления базами данных нескольких производителей. IDS (Honeywell) и IDMS (Computer Associates) - две наиболее известных коммерческих реализации. В сетевой модели существует две основные структуры данных: типы записей и наборы:

· Тип записей. Совокупность логически связанных элементов данных.

· Набор. В модели DTBG отношение один-ко-многим между двумя типами записей.

· Простая сеть. Структура данных, в которой все бинарные отношения имеют мощность один-ко-многим.

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

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

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

4. Реляционная модель

В 1970-1971 годах Е.Ф. Кодд опубликовал две статьи, в которых ввел реляционную модель данных и реляционные языки обработки данных - реляционную алгебру и реляционное исчисление.

· Реляционная алгебра - Процедурный язык обработки реляционных таблиц.

· Реляционное исчисление - Непроцедурный язык создания запросов.

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

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

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

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

Табл.1. Основные определения реляционных СУБД

Термин Определение
Реляционная модель данных Организует и представляет данные в виде таблиц или реляций.
Реляционная база данных (РБД, RDBMS). База данных, построенная на реляционной модели.
Реляция (таблица-элементарная информационная единица) Двумерная таблица, содержащая строки и столбцы данных.
Степень реляции. Количество атрибутов реляции. При том необходимо помнить, что никакие два атрибута реляции не могут иметь одинаковых имен.
Кортежи Строки реляции (таблицы), соответствуют объекта, конкретному событию или явлению.
Атрибуты Столбцы таблицы, характеризующие признаки, параметры объекта, события, явления.
Область атрибута Набор всех возможных значений, которые могут принимать атрибуты. Если в процессе работы возникает ситуация, что атрибут неприменим или значения одного или нескольких атрибутовстроки пока неизвестны, то строка запишется в базуданных с пустыми значениямиэтих атрибутов (NULL строка).
Пустое значение Значение, приписываемое атрибуту в кортеже, если атрибут неприменим или его значение неизвестно
Ключ Любой набор атрибутов, однозначно определяющий каждый кортеж реляционной таблицы.
Ключ реляции Ключ также можно описать как минимальное множество атрибутов, однозначно определяющих (или функционально определяющих)каждое значение атрибута в кортеже.
Составной ключ Ключ содержащий два или более атрибута.
Потенциальный ключ В любой данной реляционной таблице может оказаться более одного набора атрибутов. Обычно в качестве первичного ключа выбирают потенциальный ключ, которым проще всего пользоваться при повседневной работе по вводу данных.
Первичный ключ. Поле или набор полей, однозначно идентифицирующий запись.
Внешний ключ. Набор атрибутов одной таблицы, являющийся ключом другой (или той же самой) таблицы; используется для определения логических связей между таблицами. Атрибуты внешнего ключа не обязательно должны иметь те же имена, что и атрибуты ключа, которым они соответствуют.
Рекурсивный внешний ключ. Внешний ключ, ссылающийся на свою собственную реляционную таблицу.
Родительская реляция (таблица) Таблица, поля которой входят в другую таблицу.
Дочерняя реляция (таблица) Таблица, поля которой используют информацию из полей другой таблицы, являющейся по отношению к данной родительской.
Отношение один-к-одному Когда одной записи в родительской таблицы соответствует одна запись в дочерней таблице
Отношение один-ко-многим Когда одной записи в родительской таблицы соответствует несколько записей в дочерней таблице
Отношение многие-ко-многим Когда многим записям в родительской таблицы соответствуют несколько записей в дочерней таблице
Рекурсивное отношение. Отношение, связывающее объектное множество с ним самим.
View (Представления) Информационная единица РБД (по структуре аналогичная таблице), записи которой сформированы в результате выполнения запросов к другим таблицам.
Ссылочная целлостность Адекватное воспроизведение записей в ссылочных полях таблиц.
Триггер Средство обеспечения ссылочной целостности на основе механизма каскадных изменений.
Индекс Механизмы быстрого доступа к хранящимся в таблицах данных путем их предварительной сортировки.
Транзакция Такое воздействие на СУБД, которое переводит ее из одного целостного состояния в другое.

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

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

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

· при удалении записи в родительской таблицы следует удалить соответствующие записи и в дочерней таблице.

Процесс нормализации

Нормализация - процесс приведения реляционных таблиц к стандартному виду. В базе данных могут присутствовать такие проблемы как:

· Избыточность данных. Повторение данных в базе данных.

· Аномалия обновления. Противоречивость данных, вызванная их избыточностью и частичным обновлением.

· Аномалия удаления. Непреднамеренная потеря данных, вызванная удалением других данных.

· Аномалия ввода. Невозможность ввести данные в таблицу, вызванная отсутствием других данных.

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

Первая нормальная форма

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

Вторая нормальная форма.

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

Функциональная зависимость. Значение атрибута в кортеже однозначно определяет значение другого атрибута в кортеже.

Более формально можно определить функциональную зависимость следующим образом: если А и В - атрибуты в таблице В, то запись ФЗ (функциональную зависимость): А - " В обозначает, что если два кортежа в таблице В имеют одно и то же значение атрибута А, то они имеют одно и то же значение атрибута В. Это определение такжеприменимо,если А и В - множества столбцов, а не просто отдельные столбцы.

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

Процесс разбиения на две 2НФ-таблицы состоит из следующих шагов:

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

2. Атрибут, стоящий в правой части ФЗ, исключается из исходной таблицы.

3. Если более одной ФЗ нарушают 2НФ, то шаги 1 и 2 повторяются для каждой такой ФЗ.

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

Третья нормальная форма

Реляционная таблица имеет третью нормальную форму (ЗНФ), если для любой ФЗ: Х - У - Х является ключом. Заметим, что любая таблица, удовлетворяющая ЗНФ, также удовлетворяет и 2НФ. Однако обратное неверно.

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

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

2. Ключевой атрибут, входящий в составной ключ, зависит от неключевого атрибута.

Таким образом, если таблица удовлетворяет НФБК, то она также удовлетворяет ЗНФ в смысле транзитивных зависимостей и 2НФ.

Четвертая нормальная форма

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

Пятая нормальная форма.

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

Нормальная форма область/ключ.

Таблица имеет нормальную форму область/ключ (НФОК), если любое ограничительное условие в таблице является следствием определений областей и ключей. Однако не был дан общий метод приведения таблицы к НФОК.

В качестве примера, рассмотрим структуру реляционной базы данных, описывающей "отношения" пациентов и докторов в произвольной клинике (область приложения примера выбрана из-за того, что в сертификационных тестах Oracle аналогичные примеры встречаются очень часто). Пусть существует некая клиника, основные характеристики которой описываются в таблице CLINICS, в данной клинике работают доктора, основные характеристики которых описывает таблица DOCTORS. Данные пациентов клиники хранятся в таблице PATIENTS. Взаимосвязи между таблицами представлены на рис.10. (Для упрощения предполагается, что у доктора может быть несколько пациентов, которые не являются пациентами других докторов, для реализации реальной картины, когда один пациент может относиться к нескольким разным докторам, между таблицами DOCTORS и PATIENTS необходимо включить дополнительную связывающую таблицу).

Рис. 2. Диаграмма, иллюстрирующая отношения таблиц АИС.


Наименование столбца Описание
Таблица CLINICS
1 CS_NNN Индекс
2 CS_REG_NUMBER Регистрационный номер
3 CS_CITY_NNN Ссылка на справочник городов и регионов
4 CS_NAME Наименование клиники
5 CS_ADDRESS Адрес клиники
6 CS_PHONE_NUMBER Номер телефона
7 CS_TYPE Профиль клиники
Таблица DOCTORS
1 DC_NNN Индекс
2 DC_NAME Ф.И.О. доктора
3 DC_CS_NNN Ссылка на таблицу CLINICS
4 DC_DIPLOM_NUMBER Номердиплома
5 DC_SPECIALTY_NNN Ссылка на справочник специальностей
6 DC_SHTAT_NNN Ссылка на штатное расписание
7 DC_CALENDAR_NNN Ссылка на расписание приема
Таблица PATIENTS
1 PT_NNN Индекс
2 PT_REG_NUMBER Регистрационный номер
3 PT_NAME Ф.И.О. пациента
4 PT_ADDRESS Адреспациента
5 PT_POLIS_NUMBER Номерполиса
6 PT_PHONE_NUMBER Номер телефона
7 PT_BIRTHDATE Дата рождения
8 PT_FIRST_VISIT Дата первого визита
9 PT_LAST_VISIT Дата последнего визита
10 PL_PT_NNN Ссылка на таблицу платежей
Таблица PAYMENTS
PL_NNN Индекс
PL_ACCOUNT_NUMBER Номер расчетного счета
PL_PAY_NNN Ссылка на таблицу расчетов

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

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

Для таблиц:

<Псевдоним АИС>_<Псевдоним модуля АИС>_:_<Псевдоним подмодуля>_<Имя таблицы>

Например, если бы мы разрабатывали АИС клиники c сокращенным названием CSL, то все таблицы входящие в данную систему было бы целесообразно называть

CSL_<имя модуля>_<имя таблицы>.

Для столбцов:

<Псевдоним таблицы>_<имя столбца>.

Например, как показано на рис.2. Регистрационный номер пациента храниться в поле PT_REG_NUMBER, таблицы PATIENTS, имеющий псевдоним PT.

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

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

Преобразование отношений

Поля таблиц могут находиться между собой в одном из следующих отношений:

один-к-одному, один-ко-многим, многие-ко-многим и рекурсивных, определения которых приведены в табл.1. Рассмотрим преобразование отношений на примере АИС "ДОКТОР-ПАЦИЕНТ" (рис.2).

Отношение один-к-одному представляет собой такое отношение, при котором каждой записи в таблице А соответствует единственная запись в таблице В (рис.1). Применение такого типа отношений встречается крайне редко и предназначено в основном для функционального разделения информации на несколько таблиц, т.е. когда не хотят, чтобы таблица БД "распухала" от второстепенной информации. На рис.10 представлено, как используя отношение один-к-одному таблица PATIENTS преобразована в две таблицы: PATIENTS_REG и PATIENTS_KART (на рисунке показаны только основные атрибуты таблиц). Также необходимо принимать во внимание, что БД использующие такие отношения не могут быть полностью нормализованы.

Рис.1. Отношение один к одному.


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

Рис.2. Отношение один ко многим.

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


Рис.3. Отношение многие ко многим.

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

Рис.4. Отношение многие ко многим.

Учитывая требования ссылочной целостности и нормализации на основе применения рассмотренных выше типов отношений осуществляется преобразование функциональной модели бизнес - процессов и реаляционную модель. Итогом этапа является диаграмма "Сущность-связь" (часто называемая CASE диаграмма, ER-диаграама, рис.2).

Преобразование функциональной модели в реляционную.

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

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

Преобразование отношений

Поля таблиц могут находиться между собой в обном из следующих отношений: один-к-одному, один-ко-многим, многие-ко-многим и рекурсивных, определения которых представлены в табл.1. Прежде чем рассмотреть реализацию и преобразование отношений более подробно, обсудим реторический вопрос о правилах именования таблиц и столбцов. Как мы уже ранее отмечали, что практически любая АИС имеет модульную структуру и соответствено, в каждый модель входит определенное число таблиц. Пусть имеется модуль "Операционный День", условно назовем его OPDAY, тогда удобно, что все таблицы данного модуля наименовались следующим образовам OPDAY_CUSTOMERS (ТАБЛИЦА КЛИЕНТОВ), OPDAY_ACCOUNT (таблица счетов) и т.п. При наменовании столбцов таблицы желательно придерживаться следующего подхода: <краткое наименование таблицы>_<наименование столбца>. Например, для таблицы OPDAY_CUSTOMERS наименование столбцов удобно реализовать следующим образом CUST_NNN (порядковый номер записи), CUST_FIO (фио клиента), CUST_ACCOUNT_NNN (ссылка на таблицу счетов) и т.п. Практически в каждой организации, занимающейся разработкой АИС существуют свои нормы к наименованию модулей, таблиц, столбцов и объектов базы данных, однако общие принципы во многом схожи с приведенным в данных примерах. Теперь рассмотрим основные принципы преобразования отношений:

Отношение один-к-одному.

Рассмотрим пример установки отношений клиентов и счетов в АБС (см. рис.5).

Рис.5. Отношение один к одному.

Отношение ИМЕЕТ ТЕКУЩИЙ СЧЕТ представляет собой связь один-к-одному. Это означает, что клиент имеет не более одного текущего счета и каждым текущим счетом пользуется только один клиент. Если мы решим, что ключами являются №-КЛИЕНТА для CUSTOMER (КЛИЕНТ) и №-ТЕКУЩЕГО-СЧЕТА для ACCOUNT_NUMBER (ТЕКУЩИЙ СЧЕТ), то мы получим две реляционные таблицы, каждая из которых состоит из одного столбца.

CUSTOMER (CUST_NNN)

ACCOUNT (ACCOUNT_NUMBER)

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

CUSTOMER (CUST_NNN, CUST_ACCOUNT_NUMBER )

Внешнийключ: CUST_ACCOUNT_NUMBER ссылаетсяна ACCOUNT_NUMBER.

ACCOUNT (ACCOUNT_NUMBER, ACCOUNT_CUST_NNN)

Внешний ключ: ACCOUNT_CUST_NNN ссылается на CUST_NNN.

Резюме: отношение один-к-одному преобразуется путем помещения одного из объектных множеств в качестве атрибута в таблицу второго объектного множества. Его выбор определяется потребностями конкретного приложения. Во многих случаях оба варианта приемлемы.

Отношение один-ко-многим .

Предположим, что отношение ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ имеет мощность "много" со стороны ACCOUNT.

Рис.6. Отношение один ко многим.

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

Отношение многие-ко-многим.

Отношение ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ имеет мощность многие-ко-многим.

база данных реляционный


Рис.7. Отношение многие ко многим.

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

Рекурсивные отношения

Рис.8. Рекурсивные отношения.

Объектное множество WORKER(РАБОЧИЙ), дважды встречающееся на диаграмме, и это одно и то же объектное множество в обоих случаях. Обе копии объектного множества WORKER(РАБОЧИЙ) имеют одни и те же атрибуты. В этой модели два экземпляра объектного множества WORKER(РАБОЧИЙ) использованы для удобства, чтобы показать отношение SUPERVISES(КОНТРОЛИРУЕТ), существующее между объектами WORKER(РАБОЧИЙ) и WORKER(РАБОЧИЙ). Это отношение называется рекурсивным, поскольку оно связывает объектное множество с ним самим. В данном случае отношение мощности один-ко-многим означает, что одному работнику подчиняются несколько других работников.

WORKER (WORKER-ID, NAME, HOURLY-RATE, WORKER-ID)


Чтобы преобразовать объектное множество WORKER вместе с его атрибутами и отношением SUPERVISES в реляционную таблицу нужно изменить имя второго атрибута WORKER-ID на имя, соответствующее отношению SUPERVISES, котороеонопредставляет. SUPV-ID.

WORKER (WORKER-ID, NAME, HOURLY-RАТЕ, SUPV-ID)

Внешний ключ: SUPV-ID ссылается на WORKER

SUPV-ID - это рекурсивный внешний ключ, поскольку он ссылается на WORKER-ID, то есть ключ своей собственной таблицы. Таким образом, в результате преобразования рекурсивных отношений появляются рекурсивные внешние ключи.

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

Описанный процесс преобразования каждой из этих конструкций в атрибуты реляционных таблиц гарантирует, что они будут зависеть только от ключевых атрибутов. Таким образом, каждая полученная реляционная таблица будет иметь ЗНФ. Многозначные атрибуты реляционной модели встречаются только в отношениях многие-ко-многим. Поскольку они преобразуются в реляционные таблицы, обладающие составными ключами из ключевых атрибутов отдельных объектных множеств, то они гарантированно имеют 4НФ.

5. Понятие языка определения данных (ЯОД - DBTG)

Язык - средство, при помощи которого определяется структура данных или схема, а также происходит запоминание данных и манипуляция ими. Язык, которым определяется схема, называется языком определения данных (ЯОД),а язык, используемый для запоминания данных и манипуляции ими, называется языком манипуляции данными (ЯМД).

Процедура применения ЯОД и определения схемы такова:

1. Создается концептуальная модель данных.

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

3. Проверяется, существуют ли между типами записей отношения один-ко-многим. Они могут быть непосредственно реализованы в виде наборов DBTG.

4. Если есть отношения мощности многие-ко-многим, то каждое из них преобразуется в два набора путем создания записи связи.

5. Если есть n-арные отношения, то они преобразуются в бинарные отношения.

6. Применяется ЯОД для реализации схемы.

Схема состоит из следующих частей:

1. Раздел схемы. Раздел схемы DBTG, задающий имя схемы.

2. Раздел записей. Раздел схемы DBTG, определяющий каждую запись: ее элементы данных и ее адрес.

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

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

Принятого стандарта DBTG для подсхемы не существует; однако, обычно используются следующие отделы:

1. Отдел заголовка, позволяющий присвоить имя подсхеме и указать связанную с ней схему.

2. Отдел преобразования, в котором при желании производится замена имен из схемы на нужные в подсхеме.

3. Структурный отдел, в котором задается, какие записи, элементы данных и наборы из схемы должны присутствовать в подсхеме. Этот отдел состоит из разделов записей и наборов.

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

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

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

6. Язык манипуляции данными (ЯМД)

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

Основные команды ЯМД можно классифицировать следующим образом: команды передвижения, команды извлечения, команды обновления записей, команды обновления наборов.

Табл.2. Основные типы команд ЯМД.

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

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

1. Попов И.Г., Мамонов С.Г. Информационные системы. М.: Инфра, 2007.

2. Абросимов А.Г. Бородинова М.А. Теория экономических информационных систем. Учебное пособие - Самара. Изд-во Самарск.гос. экон. акад., 2007.

3. Информационные системы. Учебник /Петров В.Н. – СПб.: Питер, 2008.

4. Информационное обеспечение систем управления. Учебное пособие/Голенищев Э.П., Клименко И.В. - Ростов н/Д: Феникс, 2009.

5. Интеллектуальные информационные системы в экономике. Учебное пособие/Тельнов Ю.Ф. Издание третье, расширенное и доработанное. Серия «Экономика и бизнес». – Москва.: СИНТЕГ, 2009.

Оценить/Добавить комментарий
Имя
Оценка
Комментарии:
Где скачать еще рефератов? Здесь: letsdoit777.blogspot.com
Евгений07:59:21 19 марта 2016

Работы, похожие на Реферат: Базы данных и их сравнительные характеристики
Базы данных и информационные технологии
Лекция 1. Введение в базы данных и СУБД Одним из важнейших понятий теории базы данных является понятие информации. Здесь под информацией понимают ...
Изменения БД журнализуются следующим образом: запись в журнале соответствует некоторой операции изменения БД (например, операции удаления строки из таблицы реляционной БД).
Реляционная база данных представляет собой набор таблиц (которые Кодд назвал отношениями), каждая из которых имеет уникальное имя и состоит из строк - записей (кортежей) и столбцов ...
Раздел: Рефераты по информатике, программированию
Тип: учебное пособие Просмотров: 3929 Комментариев: 3 Похожие работы
Оценило: 1 человек Средний балл: 4 Оценка: неизвестно     Скачать
... и статистической информации в двухструктурных реляционных базах данных
Наращивание экономической и статистической информации в двухструктурных реляционных базах данных СОДЕРЖАНИЕ Введение..
Например, в столбце FAMILY содержатся только слова, в столбце DATE содержатся даты, а в столбце NUMBER содержатся целые числа, представляющие идентификаторы студентов.
В результате получается семь таблиц реляционной базы данных, где каждая сущность напрямую отражается в отдельную таблицу, атрибуты каждой сущности становятся полями этой таблицы, а ...
Раздел: Рефераты по информатике, программированию
Тип: дипломная работа Просмотров: 444 Комментариев: 2 Похожие работы
Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать
Система управления базой данных объектов гражданской обороны для ...
Государственный Комитет Российской Федерации по высшему образованию Московский Государственный Институт Радиотехники, Электроники и Автоматики ...
В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из ...
При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит ...
Раздел: Рефераты для военной кафедры
Тип: реферат Просмотров: 2034 Комментариев: 2 Похожие работы
Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать
Предмет и объект прикладной информатики
Понятие архитектуры ЭВМ. Классическая архитектура ЭВМ и принципы фон Неймана. Архитектура персональных компьютеров Общие принципы построения ...
Ключ сущности - атрибут или набор атрибутов, используемый для однозначной идентификации экземпляра сущности.
Категорийная целостность - строка не может быть занесена в БД пока не будут определены все атрибуты первичного ключа.
Раздел: Рефераты по информатике, программированию
Тип: шпаргалка Просмотров: 2836 Комментариев: 1 Похожие работы
Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать
Лекции по Основам ВТ
ОС. Функции ОС. Информационно вычислительная система (ИВС)-это совокупность технических и програмных средств которые предназначены для решения задач ...
Многие иерархические СУБД (реляционные) могут поддерживать несколько различных БД , в этом случае каждая БД на внутреннем уровне представляется одним файлом, который объединяет ...
В реляционной модели данных ключ определяется кк неизбыточное подмножество атрибутов схемы отношения , совокупность значений которых однозначно идентифицирует кортеж в отношении.
Раздел: Рефераты по информатике, программированию
Тип: реферат Просмотров: 381 Комментариев: 2 Похожие работы
Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать
Проектирование, разработка и внедрение БД ИС в экономическую ...
Дипломная работа Проектирование, разработка и внедрение БД ИС в экономическую деятельность предприятия (на примере ГП "Алушталифт") По специальности ...
Представлением отношения в реляционной модели данных является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена ...
Однако в формальном определении первичного ключа требуется обеспечение его "минимальности", т. е. в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно ...
Раздел: Рефераты по информатике, программированию
Тип: дипломная работа Просмотров: 7340 Комментариев: 2 Похожие работы
Оценило: 2 человек Средний балл: 3 Оценка: неизвестно     Скачать
Режим работы с базами данных
Кафедра экономической кибернетики Контрольная работа по дисциплине: "Системы обработки экономической информации" Режим работы с базами данных ...
Групповое отношение (набор) - это строго иерархическое отношение между записями двух типов: главной записью набора и подчиненными записями набора.
Имеются два подхода к построению таких СУБД; объектно-реляционный - совершенствование существующих реляционных СУБД и объектный.
Раздел: Рефераты по информатике, программированию
Тип: дипломная работа Просмотров: 1823 Комментариев: 2 Похожие работы
Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать
Корпоративные сети
1. Введение. В чем состоит планирование сети Корпоративная сеть - это сложная система, включающая тысячи самых разнообразных компонентов: компьютеры ...
В классической реляционной модели данных содержимым столбцов могут быть только значения базовых типов данных (целые и плавающие числа, строки символов и т.д.). Не допускается ...
системах поддерживается возможность распределенного хранения баз данных; имеется возможность написания приложений и/или методов объектов на одном или нескольких языках объектно ...
Раздел: Рефераты по информатике, программированию
Тип: реферат Просмотров: 9444 Комментариев: 4 Похожие работы
Оценило: 6 человек Средний балл: 4.8 Оценка: 5     Скачать
Реляционные модели базы данных
Введение Основные идеи современной информационной технологии базируются на концепции баз данных (БД). Согласно данной концепции основой информационной ...
Различия между первичным и альтернативными ключами могут быть важны в конкретной реализации реляционной СУБД, но с точки зрения реляционной модели данных, нет оснований выделять ...
Потенциальный ключ отношения - это набор атрибутов отношения, обладающий свойствами уникальности и неизбыточности.
Раздел: Рефераты по информатике, программированию
Тип: курсовая работа Просмотров: 5027 Комментариев: 2 Похожие работы
Оценило: 0 человек Средний балл: 0 Оценка: неизвестно     Скачать
Средства безопасности Windows Server 2003
Федеральное агентство по образованию Государственное образовательное учреждение высшего профессионального образования Дальневосточный государственный ...
При первоначальной регистрации пользователя в домене КDС помещает в TGT данные авторизации, включающие идентификаторы безопасности пользователей или групп домена учетных записей ...
С помощью механизма управления файлами операции записи значений атрибутов EFS (DDF и DRF) реализованы как обычная модификация атрибутов файла.
Раздел: Рефераты по информатике, программированию
Тип: реферат Просмотров: 2573 Комментариев: 2 Похожие работы
Оценило: 1 человек Средний балл: 4 Оценка: неизвестно     Скачать

Все работы, похожие на Реферат: Базы данных и их сравнительные характеристики (1938)

Назад
Меню
Главная
Рефераты
Благодарности
Опрос
Станете ли вы заказывать работу за деньги, если не найдете ее в Интернете?

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



Результаты(151170)
Комментарии (1843)
Copyright © 2005-2016 BestReferat.ru bestreferat@mail.ru       реклама на сайте

Рейтинг@Mail.ru