Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Концептуальная модель

Читайте также:
  1. Samasource: модель стрекозы в действии
  2. Американская модель
  3. Американская модель
  4. Английская модель
  5. Аристотелева модель разума
  6. Базовая искусственная модель
  7. Базовая модель

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

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

Чаще всего концептуальная модель базы данных включает в себя:

· описание информационных объектов, или понятий предметной области и связей между ними.

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

Концептуальная модель наиболее полно отвечает потребностям проектирования баз знаний и построена на ряде принципов, которые мы сейчас рассмотрим. Есть две большие области понятий в концептуальной модели. Обе они построены по принципу иерархического дерева. Первая область – это дерево типов данных, вторая – дерево данных. Дерево типов описывает структуру данных дерева данных, поэтому без дерева типов нет никакой логической целостности дерева данных. Для начала, рассмотрим простой пример с телевизионной камерой. Отраженный свет попадает в объектив камеры, там он разлагается на три составляющие: синий, красный, зеленый. Записывая уровень освещенности трех составляющих света 25 раз в секунду, мы можем составить представление об освещенности и отражающей способности предметов, которые мы снимаем. Теперь дадим основные определения.

Уровень упрощения – уровень детализации представления об объекте реального мира, достаточный нам для его описания и последующего использования. В предыдущем примере мы составили представление об интересующем нас объекте по его освещенности. Мы могли бы дать огромное количество характеристик, вплоть до химического состава и геометрии кристаллов, но нам это не нужно. Нам достаточно показать фильм на экране, поэтому уровень освещенности нам наиболее полно подходит. Значит, для достаточно полного представления об объекте и использования на практике представлений о нем нам достаточно упростить объект реального мира до освещенности.

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

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

Тип – набор свойств и событий объекта, описанных как единый комплекс. При этом, в зависимости от уровня упрощений, у нас может быть свойством типа другой тип. Например, совокупность трех событий дает нам тип – снимаемый предмет на камеру.

Объект – совокупность типов и свойств, объединенных в один тип, способный описать объект реального мира. В нашем примере один тип достаточен для описания объекта, снимаемого на камеру, но бывают случаи, когда одного типа недостаточно, или уровень упрощения слишком высок, чтобы можно было составить простую модель. Например, объект машина состоит из типов: кузов, рама, мотор, колеса и т.д. Эти типы, в свою очередь, тоже являются объектами, которые состоят из типов, например для колеса: обод, камера, покрышка и т.д. Для камеры: оболочка, ниппель, давление воздуха и т.д. Можно бесконечно углубляться в детализацию, но, как правило, это не требуется. Рассмотрим разные точки зрения пользователей на наши типы, в зависимости от состояния технологического процесса производства и продажи машины. Человек, который собирает колесо, рассматривает его как объект, состоящий из типов: оболочка, ниппель, давление воздуха. Он собрал колесо и передал его на главный конвейер. Далее колесо рассматривается как тип, входящий в состав объекта рама. На последней стадии сборки, нам уже не важно иметь в поле зрения свойство колесо, практически, мы потеряли его из видимости. Далее, мы рассматриваем тип рама, входящий как свойство в объект машина. Человек, который пришел покупать машину, может рассматривать его то, как объект то, как тип, входящий как свойство в объект материальное состояние и т.д. Из этих рассуждений видно, что концептуальная модель очень гибка и самодостаточна для описания внешнего мира. Мы можем двигаться от простого к сложному, описывая все, что входит в технологический процесс.

Связь – это свойство типа или свойства типа, характеризующая взаимосвязь типов в дереве данных или способ изменения значения свойства объектного типа соответственно. Бывают три типа связей: включение в дереве данных, вставка из другого типа значения свойства типа и ссылка на экземпляр типа в дереве данных. Включение позволяет строить дерево данных. Вот пример. Объект офис состоит из свойств объектного типа – комнаты. Мы не можем описать любой офис прямо в типе офис, т.к. заранее неизвестно, сколько комнат в нем будет, поэтому мы описываем связь типа офис с типом комната. Теперь создав экземпляр типа офис, мы можем добавить к этому узлу дерева данных нужное количество ветвей типа комната. Или, например, накладная состоит из шапки и списка товаров. Мы можем рассматривать шапку как узел дерева данных, а список товаров, как ветви дерева данных, исходящие из этого узла. Вставка значения свойства типа из другого типа – это способ редактирования свойства типа, при котором значение одного из свойств типа вставляется из экземпляра свойства другого типа. Например, мы можем описать связь цвета панели инструментов в программе, которое будет редактироваться из списка цветов операционной системы. При этом связь устанавливается только на время редактирования, по завершении которого связь полностью разрывается. Ссылка характерна тем, что будучи один раз установлена, не разрывается после редактирования. Это похоже на вычисляемое свойство таблицы базы данных. Если Вы измените тип, на который установлена ссылка, то во всех экземплярах типов, где есть ссылка на этот тип будет произведено изменение.

Наследование – это способ описания дерева типов. Вы можете описать тип литература, от которого наследовать типы: книга, журнал, статья. При этом поддерживается полиморфизм. Так, если в литературе есть свойство автор, произведя поиск по потомкам от литературы, Вы найдете все книги, журналы и статьи этого автора.

Имея такие богатые возможности, концептуальная модель долгое время была не реализована. Мне удалось написать реализацию концептуального подхода. Авторами концептуальной модели были Смит и Смита – американские ученые, написавшие ряд статей в 1972 – 1976 годах, которые, по общему мнению, считались утопией. В сущности, человек мыслит именно концептуально. Мы знаем, и какие характеристики есть у объекта, и значения этих характеристик. Мы знаем, что автобус и Жигули – это машины, а Жигули, Мерсы и Тойоты – это легковые автомобили. У нас в мозгах тоже есть дерево типов (наследование + описание свойств типа) и дерево данных (в сумку можно положить хлеб и огурцы).

Инфологическая модель данных "Сущность-связь"

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

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

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

Связь – ассоциирование двух или более сущностей.

 
 


Первый тип связи – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В. Например, работник и его ставка.

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

 
 


Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

В концептуальной модели это соответствует включению.

На основе этих двух видов связей, Вы можете составить более сложные связи.

 

ВОПРОС 5

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

Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

К.Дейт определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.

Стержневая сущность (стержень) – это независимая сущность. Например, при описании накладной, стержневой сущностью является шапка накладной.

Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим". Например, товар в накладной – это связь с шапкой накладной и справочником наименований товара, справочником единиц измерения.

Характеристическая сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Это что-то вроде перечисления. Например, Список поставщиков – это список указателей на отдельные записи из справочника организаций. При указании поставщика в накладной, Вы выбираете его из списка поставщиков, но реально указываете организацию из справочника организаций. Просто организация может быть и поставщиком, и покупателем, и налоговым органом, но Вам удобнее будет выбирать из более короткого списка.

Обозначающая сущность или обозначение – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности. Например, зачисление народных депутатов в разные комитеты. Один народный депутат может входить в разные комитеты.

Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.

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

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

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).

Модель «сущность-связь» (англ. “Entity-Relationship model”), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crow's Foot, Information Engineering и др.).

Основные преимущества ER-моделей:

· наглядность;

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

· ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

· объекты (сущности);

· атрибуты объектов;

· связи между объектами.

Сущность — объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

· типом связи (1:1, 1:N, N:М);

· классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.

 

 

ВОПРОС 6

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

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

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

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

 

Общее назначение процесса нормализации:

§ Исключение некоторых типов избыточности

§ Устранение некоторых аномалий обновлений

§ Разработка проекта БД, которые являются достаточно качественными представлениями реального мира(интуитивно понятен и может служить для последующего расширения)

§ Упрощение процедуры применения необходимых ограничений целостности

 

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

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

 


Дата добавления: 2015-11-30; просмотров: 56 | Нарушение авторских прав



mybiblioteka.su - 2015-2024 год. (0.013 сек.)