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




Скачать 206.8 Kb.
НазваниеМетод проектирования логической структуры реляционной бд без нормализации таблиц
Дата публикации27.03.2014
Размер206.8 Kb.
ТипАвтореферат
litcey.ru > Математика > Автореферат
На правах рукописи

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

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


Специальность: 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 в контексте системы управления почтовым сервером будет уже не атрибутом, а сущностью, т.к. там будет функциональное требование «создать почтовый ящик». Именно функциональные требования определяют к чему отнести данный тип объектов – к сущности или атрибуту сущности.
Сравним компоненты составляющие классическую модель «сущность-связь» и усовершенствованную модель «сущность-связь».




Классическая модель

Усовершенствованная модель

Компоненты

  • Сущности;

  • Атрибуты сущностей;

  • Ограничения целостности;

  • Функциональные зависимости между множествами атрибутов.




  • Сущности;

  • Атрибуты сущностей;

  • Ограничения целостности;

  • Функциональные требования;

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





Как видно, основное различие заключается в замене функциональных зависимостей на функциональные требования и связи функциональных требований с сущностями. В усовершенствованной модели рассматриваются только функциональные требования типа Insert, количество которых порядка: (2.1)
У нас нет формального критерия, что определены все функциональные требования на стадии анализа, и список функциональных требований адекватно на 100% описывает логику предметной области. Процесс сопровождения, расширения функциональности, исправления ошибок свойственен любому ПО. Но данный факт не отменяет формализацию и улучшение процесса проектирования структуры БД. Основная заслуга предлагаемой модели заключается в однозначной идентификации сущностей в заданном контексте функциональных требований. Результатом этого будет структура БД без так называемых аномалий модификации данных. Другими словами, будет получена логическая структура БД, соответствующая предметной области в контексте заданных функциональных требования более быстрым способом, чем с помощью метода нормализации.

Результаты второй главы:

  1. Впервые введена классификация функциональных требований на основе влияния реализации функциональных требований на данные в БД.

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

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

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

  5. Количество операций по идентификации сущностей согласно формуле 2.2 зависит линейно от количества атрибутов сущностей предметной области, в то время как в классическом методе количество операций порядка n!.


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


  1. На основании ТЗ составляем список ФТ в виде: подлежащее сказуемое определение. Где подлежащее соответствует классу пользователя (отвечает на вопрос кто или что). Сказуемое соответствует действию выполняемому в рамках ФТ (отвечает на вопрос что делает). Определение соответствует объекту над которым выполняется действие.

  2. На этапе анализа преобразуем список ФТ к виду ft{userclass, time, cost, status, prior, executive, type, tables, text}. В ходе данного преобразования выполняется декомпозиция каждого ФТ до атомарного состояния. Сложное ФТ не возможно привести к заданному виду, т.к. невозможно определить его тип. Массив tables содержит ровно один элемент (имя таблицы) для требований типа INSERT, UPDATE, DELETE, ALTER1. Для типа SELECT может быть более одной таблицы в массиве tables.

  3. Основной цикл алгоритма.
    //Для каждого ФТ типа INSERT создать таблицу, если только соответствующая таблица не была создана ранее на основе другого ФТ типа INSERT.



for(i=0;iif(ft[i].type==INSERT && ft[i].tables[0] отсутствует в списке dbtables[])
dbtables[]=ft[i].tables[0];

Алгоритм определения наличия таблицы ft[i].tables[0] в списке dbtables[] можно записать в следующем виде:

bool isTableinDB(t, dbtables)

{

for(k=0;k
if(структура t совпадает с dbtables[k] &&

набор ФТ заданных для t совпадает c набором ФТ заданных для dbtables[k])

return TRUE; //таблица присутствует в списке
return FALSE; //таблица в списке отсутствует

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


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


Сущности несвязанные ни с одним функциональным требованием получаем при помощи следующего запроса:
SELECT * FROM it_entity LEFT JOIN it_fr_entity ON id=entity_id WHERE fr_id IS NULL AND project_id=$project_id
Функциональные требования типа Insert несвязанные ни с одной сущностью получаем при помощи следующего запроса:

SELECT * FROM it_fr LEFT JOIN it_fr_entity ON id=fr_id WHERE type='Insert' AND entity_id IS NULL AND module_id IN (SELECT id FROM it_module WHERE project_id=$project_id)


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

 
Утверждение 1. Аномалии модификации данных в логической структуре реляционной БД спроектированной на основе предлагаемой модели предметной области отсутствуют.

 

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

Первый случай отпадает ввиду обязательности наличия первичного ключа.
Второй и третий случай невозможны для структуры реляционной БД, полученной на основе предлагаемой модели согласно определению сущности.
Второй случай — A U B образуют первичный ключ в R* и t[A][X] соответствует сущности предметной области. Если необходимо вставлять или удалять в БД информацию о сущности t[A][X], то согласно определениям сущности предлагаемой модели t[A][X] будет сущностью. А если t[A][X] будет сущностью, то при преобразовании сущностей предлагаемой модели t[A][X] будет в разных таблицах с t[A][B]. Следовательно второй случай невозможен.
Для третьего случая доказательство выглядит аналогичным образом.
Следствие 1. Добавление новых атрибутов сущностей в контексте существующих функциональных требований, т.е. без добавления новых функциональных требований типа INSERT, не приводит к аномалиям модификации данных. Другими словами, если в системе присутствуют функциональные требования ALTER первого типа (см. 2 главу), то они не могут привести к аномалиям модификации данных в БД.
Доказательство. При доказательстве теоремы 1 рассматривались произвольные атрибуты A, B, K, X некоторой сущности. Следовательно, при добавлении некоторого атрибута N к сущности реализацией которого является R* и замене в доказательстве теоремы любого атрибута A, B, K, X на N доказательство теоремы остается справедливым.
Следствие 2. Проводить процесс нормализации таблиц на основе идентификации функциональных зависимостей не требуется.
Доказательство. Целью процесса нормализации было устранение аномалий модификации данных. Поскольку аномалий модификации данных в логической структуре реляционной БД спроектированной на основе предлагаемой модели нет, то и проводить процесс нормализации не требуется.
Другими словами это означает, что таблицы находятся уже в таких нормальных формах, которые позволяют обеспечить работу с базой данных в контексте заданных функциональных требований. А это дает ответ на постановку проблемы денормализации, которая сформулирована в [4], [5].
В третьей главе также дается анализ предложенного метода и пятой нормальной формы и сравнение предложенного метода с классическим.

Результаты третьей главы:

  1. Метод проектирования реляционной структуры БД на основе усовершенствованной модели «сущность-связь» является более формализованным по сравнению с классическим методом на базе моделей сущность-связь П. Чена и расширенной моделью сущность-связь Э. Кодда, т.к. позволяет формально четко разграничить классы сущностей и их атрибуты, что позволяет избежать аномалий модификации данных.

  2. Два проектировщика БД используя предложенный метод получат практически одинаковые структуры БД на основе выявленных на стадии анализа функциональных требований и бизнес-правил.

  3. Метод на основе усовершенствованной модели «сущность-связь» является значительно менее трудоемким, чем классический метод, т.к. проводить процесс нормализации таблиц больше не требуется.

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

^ Четвертая глава посвящена CASE-средству проектирования DBDESigner.
Также в третьей главе дается описание программного продукта DBDesigner. DBDesigner является CASE-средством проектирования логической структуры реляционнной БД на основе предложенной модели. Основные функциональные возможности DBDesigner:

  • учет функциональных требований проекта;

  • учет сущностей и атрибутов сущностей и связей между сущностями;

  • учет таблиц, атрибутов таблиц и связей между таблицами;

  • отчет по реализованным и нереализованным функциональным требованиям с учетом их процентных соотношений, суммарных стоимостей и суммарных человеко-часов.

  • отчет по функциональным требованиям типа INSERT, которые не связаны ни с одним классом сущности;

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

генерация SQL-кода БД.

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

Основные результаты работы


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

  1. Разработана усовершенствованная модель «сущность-связь» устранившая неточности в определениях основных понятий, в частности введено четкое разграничение между сущностью, атрибутом сущности. Любой объект предметной области теперь можно формально отнести либо к сущности либо к ее атрибуту. Усовершенствованная модель «сущность-связь» получена из классической модели «сущность связь» путем добавления в нее функциональных требований и связей между функциональными требованиями и сущностями. Функциональные требования классифицируются по пяти типам (SELECT, INSERT, UPDATE, DELETE, ALTER).

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

  3. Разработано CASE-средство DBDesigner для частичной автоматизации проектирования структуры реляционной базы данных на основе усовершенствованной модели «сущность-связь».

  4. Предложен метод оценки стоимости и сроков проекта.

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

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

  7. Показаны границы применимости ненормализованных таблиц
^

Список публикаций по теме диссертационной работы


  1. Тарасов И. А., Проблемы качественного проектирования БД на базе классического метода: Качество Инновации Образование. М: Номер 3 (34), март 2008, с. 51-56.

  2. Тарасов И. А., Усовершенствованная ERT-модель сущность-связь: Качество Инновации Образование. М: Номер 6 (37), июнь 2008, с. 47-50.

  3. Тарасов И. А., Метод проектирования логической структуры реляционной БД на основе ERT-модели: Качество Инновации Образование. М: Номер 4 (35), апрель 2008, с. 47-50.

  4. Тарасов И. А., Основание нормальных форм таблиц и функциональных зависимостей реляционных баз данных: Проектирование телекоммуникационных и информационных средств и систем. М.: МИЭМ, 2007, с. 199.

  5. Тарасов И. А., Целостность данных, аномалии модификации данных и нормальные формы таблиц реляционных баз данных: Проектирование телекоммуникационных и информационных средств и систем. М.: МИЭМ, 2007, с. 195.

  6. Беликов С. А., Воротилин П. С., Тарасов И. А., Модель жизненного цикла разработки ИС на базе веб-технологий: Научно-техническая конференция студентов, аспирантов и молодых специалистов МИЭМ. М.: МИЭМ, 2007, с 245.

  7. Воротилин П. С., Тарасов И. А., Программно-аппаратный комплекс IT-HOSTING: Научно-техническая конференция студентов, аспирантов и молодых специалистов МИЭМ. М.: МИЭМ, 2006, с 196.

  8. Воротилин П. С., Суржко Д. А., Тарасов И. А., Интегрированная среда разработки и поддержки Web-сайтов и Web-сервисов: Научно-техническая конференция студентов, аспирантов и молодых специалистов МИЭМ. М.: МИЭМ, 2005, с 229.

  9. Галыгин А.Н., Тарасов И.А., Ширинкин Е.А. Тестирование в информационно-образовательной среде: Научно-техническая конференция студентов, аспирантов и молодых специалистов МИЭМ. М.: МИЭМ, 2002, с 135-136.



Похожие:

Метод проектирования логической структуры реляционной бд без нормализации таблиц iconМетод проектирования логической структуры реляционной бд для веб-приложений...
Анализ классического метода и case-средств проектирования логической структуры реляционной бд 14
Метод проектирования логической структуры реляционной бд без нормализации таблиц iconИзвлечения из государственного образовательного стандарта
Прикладные программы с высокой степенью автоматизации управления. Адаптируемость пакетов программ. Проектирования программ сложной...
Метод проектирования логической структуры реляционной бд без нормализации таблиц icon«утверждаю» Заведующий кафедрой гигиенических дисциплин
...
Метод проектирования логической структуры реляционной бд без нормализации таблиц iconМини-словарь глаголов с логической структурой и минимальным заполнением блоков
Мини-словарь глаголов с логической структурой и без минимального заполнения блоков (только на русском языке)
Метод проектирования логической структуры реляционной бд без нормализации таблиц iconРешение обратной задачи оптимального проектирования многоступенчатой...
Поэтому решению задачи оптимального проектирования предшествует этап формализации входящих в (1) и (4) выражений общего вида
Метод проектирования логической структуры реляционной бд без нормализации таблиц iconБлок «Технология хранения и поиска информации»
Пример задания в языке запросов поискового сервера для обозначения логической операции «или» используется символ |, а для логической...
Метод проектирования логической структуры реляционной бд без нормализации таблиц iconРазработка и анализ базы данных «Аэропорт» с помощью сводных таблиц
Исходные данные для проектирования: Счета клиентам авторемонтной мастерской, накладные закупки материалов у поставщиков
Метод проектирования логической структуры реляционной бд без нормализации таблиц iconМ. В. Ломоносова физический факультет
Указания. При решении не пользоваться стандартными программами; в качестве отчета представить собственную программу, реализующую...
Метод проектирования логической структуры реляционной бд без нормализации таблиц icon2. Морфологический анализ 2
Методы индивидуальных экспертных оценок базируются на использовании в качестве источника информации мнения одного человека. К данной...
Метод проектирования логической структуры реляционной бд без нормализации таблиц iconМоделирование как метод познания. Формы представления моделей
Роль структуры управления в ис. Функции и типовая организация современной субд 13
Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
litcey.ru
Главная страница