Что такое логическая модель данных. Логические модели баз данных. О понятии «модель данных»

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

1) Создание концептуальной модели бд.

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

2) Создание логической модели бд.

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

Для описания схемы базы данных на логическом уровне проектирования служит диаграмма “сущности-связи” (Entity-Relationship diagram или ER‑diagram). Существуют различные варианты диаграмм “сущности-связи”. Способы изображения элементов ER-диаграмм стали называть нотациями. На них одни и те же элементы графически изображаются по-разному. Известны нотация Мартина, нотация IDEF1X и др. Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. Все варианты диаграмм “сущность-связь” исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов ), и взаимосвязей между сущностями .

3) Создание физической модели бд.

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

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

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

1) Создание концептуальной модели БД

Любое помещение характеризуется следующими параметрами: информация о корпусе, в котором расположено помещение; номер помещения; этаж, на котором оно расположено; краткое описание расположения помещения в корпусе; размеры помещения (ширина, длина и высота потолка в метрах).

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

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

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

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

2) Создание логической модели БД

Выделим основные информационные объекты, информацию о которых будет храниться в базе данных, атрибуты этих объектов и связи между объектами. Логическую модель представим в виде диаграммы «сущности-связи» в нотации IDEF1X (рис.1).

Рис. 1. Логическая модель БД

3) Создание физической модели БД

Выбрав СУБД Oracle в качестве целевой, преобразуем логическую модель в физическую (рис. 2).

Рис. 2. Физическая модель БД

На рисунке 1 представлена логическая модель базы данных студенческого общежития.

Рисунок 1 – логическая модель

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

2.2 Сущности

Данная БД содержит 16 сущностей. Разберем каждую из них и связи между ними.

Сущность Форм_об содержит два атрибута: Ном_фо – порядковый номер формы обучения, и Форм_об – форма обучения, первый из которых является ключевым. В этой сущности содержатся возможные варианты форм обучения (бюджетная и контрактная).

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

Сущность Факультет содержит информацию о факультетах. Первый атрибут (ключевой) Ном_фак – порядковый номер факультета, второй атрибут Факультет – сокращенное наименование факультета.

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

Сущность Комната содержит номера комнат и количество свободных в них мест. Так как по условию не должно быть незаселенных комнат и в комнате всего 3 места, нужно будет выставить соответствующее ограничение на ввод данных.

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

Сущность Группа содержит номер группы, определяющие критерии – номер факультета и номер специальности, а также курс.

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

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

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

Сущность Студ_измен служит для связи сущностей Студент и Изменения . Она содержит номер изменения, номер студенческого билета и дату, когда произошло изменение.

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

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

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

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

В сущности Родители содержится информация о родителях студента, такая как ФИО отца и матери и состояние их брака, что может потребоваться для выплат дополнительных пособий студенту.

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

Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.

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

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

ERD-диаграммы

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

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

Рис. 6.1. Пример ERD-диаграммы,

Определение сущностей и атрибутов

Сущность - это субъект, место, вещь, событие или понятие, содержащие информацию. Точнее, сущность - это набор (объединение) объектов, называемых экземплярами. В приведенном на рис. 6.1 примере сущность CUSTOMER (клиент) представляет всех возможных клиентов. Каждый экземпляр сущности обладает набором характеристик. Так, каждый клиент может иметь имя, адрес, телефон и т. д. В логической модели все эти характеристики называются атрибутами сущности.

На рис. 6.2 показана ERD-диаграмма, включающая в себя атрибуты сущностей.

Рис. 6.2. ERD- диаграмма с атрибутами

Логические взаимосвязи

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

Некоторые примеры взаимосвязей:

команда включает много игроков,
самолет перевозит много пассажиров,
продавец продает много продуктов.

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

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

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

Проверка адекватности логической модели

Если взаимосвязи между сущностями были правильно установлены, то можно составить предложения, их описывающие. Например, по модели, показанной на рис. 6.3, можно составить следующие предложения:

Самолет перевозит пассажиров. Много пассажиров перевозятся одним самолетом.

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

Рис. 6.3. Пример логической модели со взаимосвязью

Модель данных, основанная на ключах

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

Выбор первичного ключа

При создании сущности необходимо выделить группу атрибутов, которые потенциально могут стать первичным ключом (потенциальные ключи), затем произвести отбор атрибутов для включения в состав первичного ключа, следуя следующим рекомендациям:

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

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

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

Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key). ERWin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).

Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.

При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.

Пример

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

Таблица 6.1. Атрибуты сущности «Студент»

Атрибут	Описание
Номер	Уникальный номер для идентификации пользователя
Ф.И.О.	Фамилия, имя и отчество пользователя
Пароль	Пароль для доступа в систему
Возраст	Возраст студента
Пол	Пол студента
Характеристика	Memo-поле с общей характеристикой пользователя
E-mail	Адреса электронной почты
Телефон	Номера телефонов студента (домашний, рабочий)
Опыт работы	Специальности и опыт работы студента по каждой из них
Специальность	Специальность, получаемая студентом при окончании учебного заведения
Специализация	Направление специальности, по которому обучается студент
Иностранный язык	Список иностранных языков и уровень владения ими
Тестирование	Список тестов и отметки о их прохождении
Экспертная оценка	Список предметов с экспертными оценками по каждому из них
Оценки по экзаменам	Список сданных предметов с оценками

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

Таблица 6.2. Атрибуты сущности «Опыт работы»

Таблица 6.3. Атрибуты сущности «Иностранный язык»

Таблица 6.4. Атрибуты сущности «Тестирование»

Таблица 6.5. Атрибуты сущности «Экспертная оценка»

Атрибут	Описание
Дисциплина	Наименование дисциплины, по которой оценивался студент
Ф.И.О. преподавателя	Ф.И.О. преподавателя, который оценивал студента
Оценка	Экспертная оценку преподавателя
Атрибут		Описание
Предмет		Название предмета, экзамен по которому сдавался
Оценка		Полученная оценка

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

Рис. 6.4. ERD-диаграмма БД студентов

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

Следующим этапом при построении логической модели является определение ключевых атрибутов и типов атрибутов.

Таблица 6.7. Типы атрибутов

Атрибут	Тип






Характеристика

Специальность
Специализация

Место работы

Уровень владения
Название
Описание

Дисциплина
Ф.И.О. преподавателя

Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Студент» это будет уникальный номер, для сущности «Опыт работы» все поля являются ключевыми, так как по разным специальностям студент может иметь разный опыт работы в разных фирмах. Сущность «Тест» определяется названием, так как студент по одному тесту может иметь только одну оценку. Оценка по экзамену определяется только названием предмета, экспертная оценка зависит от преподавателя, который ее составил, поэтому в качестве ключевых атрибутов выберем «Дисциплину» и «Ф.И.О. преподавателя». У сущности «Иностранный язык» уровень владения зависит только от наименования языка, следовательно, это и будет являться ключевым атрибутом.

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

Рис. 6.5. ERD-диаграмма БД студентов с ключевыми атрибутами

Контрольные вопросы

Назовите основные части ERD-диаграммы.
Цель ERD-диаграммы.
Что является основным компонентом реляционных БД?
Что называется сущностью?
Сформулируйте принцип именования сущностей.
Что показывает взаимосвязь между сущностями?
Назовите типы логических взаимосвязей.
Каким образом отображаются логические взаимосвязи?
Опишите механизм проверки адекватности логической модели.
Что называется первичным ключом?
Назовите принципы, согласно которым формируется первичный ключ.
Что называется альтернативным ключом?
Что называется инверсионным входом?
В каком случае образуются внешние ключи?

Тема, цель работы.
ERD-диаграмма БД Служба занятости с атрибутами и ключами.
Выводы по работе

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

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

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

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

Иерархическая;

Сетевая;

Реляционная.

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

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

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

Описание пользователей и групп пользователей системы

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

Модель предметной области

Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model). Модель "сущность-связь" основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Категории «сущность» и «связь» объявляются основополагающими, и разделение их производится на этапе создания конкретных представлений некоторой предметной области.

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

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

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

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

Модель «сущность-связь» представлена в Приложении Е.

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

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

Программный продукт представлен проектом - Cinema, который имеет 4 связанных между собой таблицы:

Bilety - информация реализованных билетах;

Films - информация о всех имеющихся в кинотеатре фильмах;

Seansy - информация о времени проведения сеансов и стоимости билетов на эти сеансы;

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

При выполнении основных функций СУБД должна использовать различные описания данных. Рассмотрим порядок создания этих описаний.

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

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

Концептуальная модель предметной области

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

На рис. 7 приведен фрагмент концептуальной модели предметной области "Предприятие".

Рисунок 7 - Концептуальная модель ИС "Предприятие"

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

Модель данных - инструментарий для отображения предметной области, определяется:

Допустимой организацией данных;

Ограничениями целостности (семантикой);

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

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

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

Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

Можно выделить три основные виде логических моделей:

Иерархическую модель;

Сетевую модель;

Реляционную модель.

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

Рисунок 8 - Пример логической модели данных

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

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

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

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

На еще более низком уровне находится физическая модель данных.

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

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

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

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