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

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

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

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

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

диаграмм сущность-связь (Entity Relationship Diagram, ERD);

модель данных, основанная на ключах (Key Based model, KB);

полная атрибутная модель (Fully Attributed model, FA).

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

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

Модель данных, основанная на ключах, — более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.

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

В данных методических указаниях будет рассмотрена модель данных, основанная на ключах.

Основные компоненты диаграммы ERwin – это сущности, атрибуты и связи.

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

Сущность на диаграмме изображается прямоугольником. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения (см. рис. 34).

Рис. 34. Сущность с заполненными атрибутами.

Экземпляры независимойсущности могут быть уникально идентифицированы без определения ее связей с другими сущностями;зависимаясущность, наоборот, не может быть уникально идентифицирована без определения ее связей с другими сущностями. Зависимая сущность отображается в ERwin прямоугольником с закругленными углами (см. рис. 35).

Рис. 35. Зависимая сущность с заполненными атрибутами.

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

Читайте также:  Плата перемычка сканворд 7 букв

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

Унификация— это объединение двух или более групп атрибутов внешних ключей в один внешний ключ (группу атрибутов), в предположении, что значения одноименных атрибутов в дочерней сущности всегда одинаковы. Рассмотрим пример: сущность "сотрудник" имеет первичный ключ "код сотрудника" и связан идентифицирующей связью с сущностями "супруга" и "дети". При этом происходит миграция первичного ключа в зависимые сущности. В свою очередь, сущность "супруга" связана не идентифицирующей связью с сущностью "дети". Имеются два пути миграции ключа, однако в сущности "дети" атрибут "код сотрудника" появляется один раз в качестве элемента первичного ключа. Существуют случаи, когда унификация атрибутов дает неверный с точки зрения предметной области результат. Для отмены унификации для атрибутов вводятся имена ролей.

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

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

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

Читайте также:  Как повысить оперативную память на андроид

Для добавления сущности следует нажать кнопку , а затем – щелкнуть «мышью» по свободному месту диаграммы. После этого по созданному элементу

следует щелкнуть два раза левой кнопкой «мыши». В открывшемся диалоговом окне Attributes(см. рис. 36) следует:

при нажатии кнопки ввести название сущности;

при нажатии кнопки Newввести название и тип добавляемого атрибута (список форматов возможных типов представлен в табл. 5), а при необходимости установить ему ключевой признак вводом флажкаPrimary Key.

Рис. 36. Окно для заполнения атрибутов сущности.

Для построения логической модели БД мы воспользовались методологией проектирования ERwin.ERwin относится к средствам проектирования баз данных, обеспечивающих моделирование данных и разработку схем баз данных для основных СУБД [7].

ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Sybase, MSSQLServer и др.) и реинжиниринг баз данных. С помощью Erwin разрабатываются небольшие ИС или крупные ИС с разбиением на подсистемы.

Логический уровень- это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

В логической модели БД (рисунок 3.4) будут представлены следующие сущности и их атрибуты:

  • 1. Инструктор (фамилия; имя; отчество; дата рождения; адрес; телефон; номер паспорта);
  • 2. Учащийся (номер паспорта; фамилия; имя; отчество; дата рождения; адрес; телефон);
  • 4. Практические занятий (номер занятия; ФИО учащегося; номер автомобиля номер площадки, время начала, дата, время выполнения);
  • 5. Теоретические занятия (номер занятия; наименование, ФИО учащегося; номер аудитории; время начала; дата; длительность);

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

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

Физическая модель БД представлена на рисунке 3.5.

Рис. 3.5 Физическая модель данных

Построенные модели облегчат процесс создания базы данных для информационной системы юношеской автомобильной школы. SQL-код можно получить непосредственно из case-средста Erwin.

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

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

Читайте также:  Почему на роутере горит красная кнопка

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

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

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

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

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

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

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

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

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

Ссылка на основную публикацию
Что дает geforce experience
The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator...
Форге оф импаерс великие строения
Другое название: Кузница Империй Ниже мы приводим подробный гайд по игре Forge of Empires с советами как вам быстрее отстроить...
Форза хорайзен 3 список машин
Серия игр Forza всегда поражала количеством доступных автомобилей. На момент выхода игры доступно уже более 150 автомобилей, а разработчики обещают...
Что дает перепрошивка смартфона
К моему большому сожалению, такой огромный пласт гик-культуры, как прошивка смартфонов, очень мало обозревается на IT-сайтах. Но бьюсь об заклад,...
Adblock detector