авторефераты диссертаций БЕСПЛАТНАЯ РОССИЙСКАЯ БИБЛИОТЕКА - WWW.DISLIB.RU

АВТОРЕФЕРАТЫ, ДИССЕРТАЦИИ, МОНОГРАФИИ, НАУЧНЫЕ СТАТЬИ, КНИГИ

 
<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ

Pages:   || 2 |

Метод проектирования логической структуры реляционной бд без нормализации таблиц

-- [ Страница 1 ] --

На правах рукописи

Тарасов Игорь Александрович

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

Специальность: 05.13.11 - Математическое и программное

обеспечение вычислительных машин, комплексов и компьютерных

сетей

Диссертация на соискание ученой степени

кандидата технических наук

Москва 2009

 

 Работа выполнена в Московском государственном институте электроники и математики.

 

Научный руководитель: к. т. н. А. В. Белов

 

Официальные оппоненты:

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

Ведущая организация ____________________________________________

название

Защита состоится _____________________________________на заседании

дата, время

диссертационного совета Д212.133.01 при Московском государственном институте электроники и математики по адресу: Москва, Б. Трехсвятительский пер., д. 3.

С диссертацией можно ознакомиться в библиотеке

Московоского государственного института электроники и математики.

 

Автореферат разослан ____________________________________________

дата

Ученый секретарь

диссертационного совета Бузников С. Е.

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

И. А. Тарасов

Общая характеристика работы

Актуальность работы

Проектирование логической структуры реляционной базы данных осуществляется на основе модели «сущность-связь» П. Чена или расширенной реляционной модели Э. Кодда. Методы проектирования описаны в работах П. Чена, Э. Кодда, К. Дж. Дейта, Р. Фагина, Д. Кренке, Г. Гарсиа-Молина и др. Данные модели «сущность-связь» не имеют формальных определений сущности и атрибута сущности, а также не учитывают функциональных требований (ФТ) к информационной системе (ИС) на стадии проектирования. Для разработки веб-приложений, которые описываются в большой степени действиями с ИС, а не данными, которые в ней хранятся, такая ситуация является противоестественной. Существующие методы проектирования логической структуры реляционной базы данных имеют следующие недостатки:

  1. Сложность и трудоемкость идентификации функциональных зависимостей (ФЗ);
  2. Зависимость конечного результата проектирования от опыта и субъективного взгляда проектировщика, а не от метода проектирования;
  3. Проблема идентификации сущностей и атрибутов сущностей.

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





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

Цель диссертационной работы

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

Объект исследования

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

Методы исследования

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

Научная новизна

Основными научными результатами являются:

  1. Усовершенствованная модель сущность-связь, отличающаяся от известных тем, что она позволяет однозначно идентифицировать сущности и атрибуты сущностей на основе ФТ к ИС. Впервые введена классификация функциональных требований на основе типа воздействия их реализации на ИС.
  2. Метод проектирования логической структуры реляционной БД, отличающийся от известных тем, что он позволяет полностью избежать аномалий модификации данных в контексте заданных требований к ИС, значительно сокращает трудоемкость процесса проектирования логической структуры БД, т.к. не требует производить процесс нормализации таблиц основанный на идентификации ФЗ.
  3. Программное обеспечение DBDesigner, отличающееся от известных тем, что поддерживает предлагаемую усовершенствованную модель «сущность-связь», метод проектирования логической структуры реляционной БД на основе данной модели, в частности: поддерживает типизацию ФТ, позволяет установить связи между ФТ и сущностями предметной области, выдает отчеты по несвязанным функциональным требованиям и сущностям.

Достоверность полученных результатов

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

Практическая ценность

Результаты работы реализованы и имеют практическое применение в виде системы управления информацией сайтов ITCMS, системы управления взаимоотношениями с клиентами ITCRM, системы тестирования, системы управления взаимоотношениями с клиентами, системы поиск персонала и вакансий, системы управления хостингом. На базе программного обеспечения ITCMS функционирует более 300 веб-сайтов.

Апробация результатов

Основные положения и результаты диссертации докладывались и обсуждались на заседаниях кафедр «РТУиС», «МОСОИиУ», «Кибернетика», «ИТАС» МИЭМ в 2000-2007 годах, на научно-технической конференции студентов, аспирантов и молодых специалистов МИЭМ, международной студенческой школе-семинаре «Новые информационные технологии» Крым. Разработанный метод проектирования внедрен в компании ITSoft.

Публикации

Отдельные положения диссертации отражены в 11 печатных работах.

Объем работы и структура диссертации

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

Краткое содержание работы

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



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

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

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

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

В первой главе впервые показаны границы применимости таблиц в 1НФ, 2НФ, 3НФ. Классифицированы четыре случая возникновения аномалий модификации данных. Пусть A, B, K, X не пересекающиеся подмножества множества атрибутов таблицы R*. Пусть t - некоторый кортеж совместимый с R*. R — множество кортежей находящихся, в таблице R*. Аномалия модификации данных возникает в следующих случаях:

  1. В R* нет первичного ключа. Аномалия редактирования и удаления данных в случае наличия двух кортежей с одинаковыми значениями, но описывающими разные объекты предметной области. (Таблица не находится в 2НФ.)
  2. A U B образуют первичный ключ в R*, t[A][X] (проекция t на атрибуты A и X) соответствует сущности предметной области, тогда нельзя вставить в БД информацию о данной сущности и удалить информацию из БД о данной сущности. (Таблица либо не находится в 2НФ, либо находится в 3НФ, но не в 3НФБК.)
  3. K — первичный ключ в R*, A и B множества неключевых атрибутов, t[A][B] соответствует сущности предметной области, тогда нельзя вставить в БД информацию о данной сущности и удалить информацию из БД о данной сущности. (Таблица находится в 2НФ, но не находится в 3НФ.)
  4. A U B U K образуют первичный ключ R*, t[A][B] соответствует сущности предметной области, тогда нельзя вставить в БД или удалить информацию о данной сущности.

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

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

Сущность (entity) – различимый объект, понятие, которое может быть четко идентифицировано [1].

Сущность (entity) – это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать [2].

Сущность (entity) – это абстрактный объект определенного вида [3].

Сущность (entity) – это нечто, о чем хранится информация [4].

Сущность – это любой конкретный или абстрактный объект в проблемной области. [5]

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

  1. Дейт К. Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом "Вильямс", 2006. — 1328 с.
  2. Д. Кренке Теория и практика построения баз данных. 9е изд. — СПб.: Питер, 2005 — 859 с.
  3. Г. Гарсиа-Молина и др. Системы баз данных. Полный курс. — М.: Издательский дом "Вильямс", 2004. — 1088 с.
  4. Джен Л. Харрингтон Проектирование реляционных баз данных — М.: Издательство «Лори», 2006 — 230 с.
  5. ГОСТ 34.320-96 Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы

В первой главе были получены следующие результаты:

  1. Разные проектировщики идентифицируют разные функциональные зависимости, а следовательно получат разные структуры данных на основе одного и того же технического задания.
  2. Идентификации всех функциональных зависимостей процесс очень трудоемкий, т.к. нужно рассмотреть не менее потенциальных функциональных зависимостей.
  3. Зависимость конечного результата проектирования от опыта и субъективного взгляда проектировщика, а не от формального метода проектирования.
  4. Существующие определения сущности и атрибута сущности не являются определениями. Используя их невозможно формально классифицировать объект предметной области как сущность или как атрибут другой сущности.
  5. В процессе проектирования структуры БД необходимо учитывать ФТ к ИС
  6. Формальное применение процесса нормализации таблиц может дать плохую структуру БД с точки зрения производительности, трудоемкости разработки приложения для работы с БД.
  7. Впервые классифицированы случаи, когда можно работать с таблицами в 1НФ, 2НФ и 3НФ.
  8. Впервые дано определение структуры БД неадекватной предметной области.
  9. Показаны ошибки в теории Рональда Фагина о доменно-ключевых нормальных формах.
  10. Впервые показан пример таблицы, которая находится в 3НФБК и которую невозможно привести к 4НФ.

Вторая глава посвящена описанию усовершенствованной модели «сущность-связь», которая позволяет однозначно идентифицировать сущности и атрибуты сущностей на основе ФТ к ИС.

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

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

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

  1. Снятие денег с одного счета
  2. Зачисление денег на другой счет

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

Функциональное требование имеет следующий набор свойств:

  • Класс пользователя ИС;
  • Время реализации в часах;
  • Стоимость;
  • Статус;
  • Приоритет;
  • Исполнитель;
  • Тип (SELECT, INSERT, UPDATE, DELETE, ALTER);
  • Список таблиц для требования типа SELECT, или строго одна таблица для требования типа INSERT, UPDATE и DELETE;
  • Текстовое описание.

Будем обозначать функциональное требование в символьном виде следующим образом: ft{userclass, time, cost, status, prior, executive, type, tables, text}.

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

  • Отобразить данные результат выполнения SQL-запроса SELECT
  • «вставить», «создать», «добавить» и т.п. данные в таблицу БД, результат выполнения SQL-запроса INSERT
  • Обновить данные, результат выполнения SQL-запроса UPDATE
  • Удалить данные,  результат выполнения SQL-запроса DELETE
  • Изменить структуру данных ALTER.

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

  1. Требование, которое добавляет (удаляет) в таблицу атрибут;
  2. Требование, которое создает новую таблицу;
  3. Требование, которое добавляет (удаляет) внешний ключ в существующую таблицу.

Требования типа ALTER второго и третьего типов практически не встречаются на практике. При этом они изменяют существенным образом структуру базы данных, что влечет модернизацию ИС. Классы таких систем рассматриваться не будут. Ограничимся системами с функциональными требованиями типа (SELECT, INSERT, UPDATE, DELETE и ALTER первого типа). Требование ALTER первого типа не влияет существенным образом на проект БД и ИС. Это будет доказано в третьей главе.

Функциональное требование является атомарным, если оно приведено к виду ft{userclass, time, cost, status, prior, executive, type, tables, text}. Для сложного (неатомарного) требования невозможно установить его тип. Например, для функционального требования «перевод денег со счета на счет» невозможно определить его тип, т.к. очевидно, что оно состоит из нескольких операций модификации данных в БД.

Введем усовершенствованные определения.

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

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

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

 

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

Атрибут сущности – объект, который необходимо хранить в БД и для которого нет функционального требования типа INSERT. Примеры: имя, фамилия, дата рождения, рост, цвет, телефонный номер сотрудника, email клиента.

Важно пояснить, что email в контексте системы управления почтовым сервером будет уже не атрибутом, а сущностью, т.к. там будет функциональное требование «создать почтовый ящик». Именно функциональные требования определяют к чему отнести данный тип объектов – к сущности или атрибуту сущности.



Pages:   || 2 |
 

Похожие работы:







 
© 2013 www.dislib.ru - «Авторефераты диссертаций - бесплатно»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.