2010-11-25 2 views

ответ

44

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

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

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

Here является хорошей картиной, которая описывает каждый из трех уровней.

+5

Этот ответ верен, если вы точно знаете, что собираетесь построить систему в реляционной базе данных. Моделирование концептуальных данных также очень полезно, если вы используете нереляционную базу данных (например, NoSQL, такую ​​как Graph Database) или вообще не имеете базы данных! (например, ваш собственный код или выяснить правильные классы и объекты в вашем коде или вообще не использовать код при моделировании домена или бизнеса) – 2012-02-01 04:15:11

+0

@veljkoz: Я где-то изучал этот концептуальный логический уровень. Вот ссылка, пожалуйста, очистите мое сомнение.http: //jcsites.juniata.edu/faculty/rhodes/dbms/dbarch.htm – Sudhir 2014-02-08 06:07:17

+0

@Sudhir Они оба обсуждают тот же уровень дизайна, но с разным уровнем детализации, поэтому да, вы могли бы назвать их с тем же именем (хотя я лично предпочел бы выбрать «логический», чем «концептуальный», как инкапсулирующее имя). Это теория, поэтому вы, вероятно, найдете и другие варианты. – veljkoz 2014-02-10 15:46:05

8

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

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

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

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

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

1

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

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

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

Из того, что я могу практически видеть (и без словечек)

физическая модель: на самом деле таблица. Маленькие картинки содержат в них типы данных и называемые ограничениями pk/fk. Логическая модель: нажмите маленькую кнопку на моем инструменте (используя Oracles SQL Developer Data Modeller, у меня нет лицензии erwin и 2010 visio больше не обращаются с инженерами из БД) , а затем изображения на экране слегка меняются. Типы данных исчезли, а имена ограничений исчезли, а цвета представлений таблиц изменились на фиолетовые (так что теперь я называю их сущностями).

ok. так что моя концептуальная модель будет выглядеть иначе: точно так же, как моя логическая модель, минус поля. Я думаю, что для этого есть нечто большее. Говоря о том, что его «семантическое» представление данных звучит действительно красиво и фантастично, но не имеет смысла для тех, кто раньше не делал этого.

-1

логическая модель данных

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

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

2

Модель

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

После того как информация компилируется, отчеты и диаграммы сделаны, в том числе следующие:

диаграмма отношения

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

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

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

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

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

Резюме:

моделирование базы данных 1.Logical в основном для сбора информации о потребностях бизнеса и не предполагает проектирование базы данных; тогда как физическое моделирование баз данных в основном требуется для фактического проектирования базы данных. 2. Логическое моделирование базы данных не включает индексы и ограничения; логическая модель базы данных для приложения может использоваться в различных программах и реализациях баз данных; тогда как физическое моделирование базы данных является специфическим программным и аппаратным обеспечением, имеет индексы и ограничения. 3. Моделирование логической базы данных; ERD, диаграммы бизнес-процессов и документацию обратной связи с пользователями; тогда как физическое моделирование базы данных включает в себя; диаграмму модели сервера, документацию по дизайну базы данных и документацию обратной связи с пользователями.

Подробнее: Разница между логической и физической моделью базы данных | Разница между | Логическая и физическая модель базы данных http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg

0

Большинство ответов здесь строго связано с обозначениями и синтаксисом моделей данных на разных уровнях абстракции. Ключевое различие никому не упоминалось. Концептуальные модели поверхностных концепций. Понятия относятся к другим понятиям по-другому, что Сущность относится к другому Сущности на Логическом уровне абстракции. Понятия ближе к типам. Обычно на концептуальном уровне отображаются типы вещей (это не означает, что вы должны использовать термин «тип» в своем соглашении об именах) и отношения между такими типами. Следовательно, существование отношений «многие ко многим» не является правилом, а скорее следствием отношений между элементами типа. В логических моделях сущности представляют один экземпляр этой вещи в реальном мире. В концептуальных моделях не ожидается описания экземпляра сущности и их отношений, а скорее описание «типа» или «класса» этого конкретного объекта. Примеры: - Автомобили с колесами и колесами используются в транспортных средствах. На концептуальном уровне это отношение «многие ко многим» - конкретный автомобиль (например, автомобиль) с одним конкретным регистрационным номером имеет 5 колес и каждое конкретное колесо, каждый с серийным номером относится только к той конкретной машине , На логическом уровне это соотношение «один ко многим».

Концептуальные покрытия "типы/классы". Логические обложки «экземпляры».

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

Ну, я думаю, это мой 2 цента ...

0

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

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

Смежные вопросы