Проектирование модели данных - Основы проектирования баз данных
Этапы проектирования данных
Предметная область - часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов, например, предприятие - цехами, дирекцией, бухгалтерией и т. д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область.
В теории проектирования информационных систем предметную область (или, если угодно, весь реальный мир в целом) принято рассматривать в виде трех представлений:
- - представление предметной области в том виде, как она реально существует - как ее воспринимает человек (имеется в виду проектировщик базы данных) - как она может быть описана с помощью символов.
Т. е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.
Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC): информационный база данные моделирование
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
- - обследование предметной области, изучение ее информационной структуры - выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами - моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
Физическое проектирование - определение особенностей хранения данных, методов доступа и т. д.
Различие уровней представления данных на каждом этапе проектирования представлено в следующей таблице:
Представление данных с помощью модели "сущность-связь"
Назначение модели
Прежде, чем приступать к созданию системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятиях той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity-relationship model, ER-model).
Модель "сущность-связь" основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным является тот факт, что из модели "сущность-связь" могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.
Отметим, что модель "сущность-связь" не является моделью данных в строгом смысле, поскольку не определяет операций над данными и ограничивается описанием только их логической структуры.
Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом.
Элементы модели
Любой фрагмент предметной области может быть представлен как Множество сущностей, между которыми существует некоторое Множество связей. Дадим определения:
Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов. Примеры: конкретный человек, предприятие, событие и т. д.
Набор сущностей (entity set) - множество сущностей одного типа(обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т. д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.
Сущность фактически представляет из себя множество атрибутов, которые описывают свойства всех членов данного набора сущностей.
В дальнейшем для определения сущности и ее атрибутов будем использовать обозначение вида
СОТРУДНИК (ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ).
Например, отделы, на которые подразделяется предприятие, и в которых работают сотрудники, можно описать как ОТДЕЛ (НОМЕР_ОТДЕЛА, НАИМЕНОВАНИЕ).
Множество значений (область определения) атрибута называется доменом. Например, для атрибута ВОЗРАСТ домен (назовем его ЧИСЛО_ЛЕТ) задается интервалом целых чисел больших нуля, поскольку людей с отрицательным возрастом не бывает.
В упомянутой статье П. Чена атрибут определяется как функция, отображающая набор сущностей в набор значений или в декартово произведение наборов значений. Так атрибут ВОЗРАСТ производит отображение в набор значений (домен) ЧИСЛО_ЛЕТ. Атрибут ИМЯ производит отображение в декартово произведение наборов значений ИМЯ, ФАМИЛИЯ и ОТЧЕСТВО.
Отсюда определяется ключ сущности - группа атрибутов, такая, что отображение набора сущностей в соответствующую группу наборов значений является взаимнооднозначным отображением. Другими словами: ключ сущности - это один или более атрибутов, уникально определяющих данную сущность. В нашем примере ключом сущности СОТРУДНИК является атрибут ТАБЕЛЬНЫЙ_НОМЕР (конечно, только в том случае, если все табельные номера на предприятии уникальны).
Связь (relationship) - это ассоциация, установленная между несколькими сущностями. Примеры:
- - поскольку каждый сотрудник работает в каком-либо отделе, между сущностями СОТРУДНИК и ОТДЕЛ существует связь "работает в" или ОТДЕЛ-РАБОТНИК; - так как один из работников отдела является его руководителем, то между сущностями СОТРУДНИК и ОТДЕЛ имеется связь "руководит" или ОТДЕЛ-РУКОВОДИТЕЛЬ; - могут существовать и связи между сущностями одного типа, например связь РОДИТЕЛЬ - ПОТОМОК между двумя сущностями ЧЕЛОВЕК.
Следует отметить, что в методике проектирования данных есть своеобразное правило хорошего тона, согласно которому сущности обозначаются с помощью имен существительных, а связи - глагольными формами. Данное правило, однако, не является обязательным.
К сожалению, не существует общих правил определения, что считать сущностью, а что связью. В рассмотренном выше примере мы положили, что "руководит"- это связь. Однако, можно рассматривать сущность "руководитель", которая имеет связи "руководит" с сущностью "отдел" и "является" с сущностью "сотрудник".
Связь также может иметь атрибуты. Например, для связи ОТДЕЛ-РАБОТНИК можно задать атрибут СТАЖ_РАБОТЫ_В_ОТДЕЛЕ.
Роль сущности в связи - функция, которую выполняет сущность в данной связи. Например, в связи РОДИТЕЛЬ-ПОТОМОК сущности ЧЕЛОВЕК могут иметь роли "родитель" и "потомок". Указание ролей в модели "сущность-связь" не является обязательным и служит для уточнения семантики связи.
Набор связей (relationship set) - это отношение между N (причем N не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.
Хотя, строго говоря, понятия "связь" и "набор связей" различны (первая является элементом второго), их, тем не менее, очень часто смешивают. Поэтому, в дальнейшем также будем часто пользоваться терминами "связь" имея в виду "набор связей" и "сущность" имея в виду "набор сущностей".
В случае N=2, т. е. когда связь объединяет две сущности, она называется бинарной. Доказано, что N-арный набор связей (N>2) всегда можно заменить множеством бинарных, однако первые лучше отображают семантику предметной области.
То число сущностей, которое может быть ассоциировано через набор связей с другой сущностью, называют степенью связи. Рассмотрение степеней особенно полезно для бинарных связей. Могут существовать следующие степени бинарных связей:
Один к одному (обозначается 1 : 1 ). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. В рассмотренном нами примере это связь "руководит", поскольку в каждом отделе может быть только один начальник, а сотрудник может руководить только в одном отделе. Данный факт представлен на следующем рисунке, где прямоугольники обозначают сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией.
Другой важной характеристикой связи помимо ее степени является класс принадлежности входящих в нее сущностей или кардинальность связи. Так как в каждом отделе обязательно должен быть руководитель, то каждой сущности "ОТДЕЛ" непременно должна соответствовать сущность "СОТРУДНИК". Однако, не каждый сотрудник является руководителем отдела, следовательно в данной связи не каждая сущность "СОТРУДНИК" имеет ассоциированную с ней сущность "ОТДЕЛ".
Таким образом, говорят, что сущность "СОТРУДНИК" имеет обязательный класс принадлежности (этот факт обозначается также указанием интервала числа возможных вхождений сущности в связь, в данном случае это 1,1), а сущность "ОТДЕЛ" имеет необязательный класс принадлежности (0,1). Теперь данную связь мы можем описать как 0,1:1,1. В дальнейшем кардинальность бинарных связей степени 1 будем обозначать следующим образом:
Один ко многим ( 1 : n ). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Такова связь ОТДЕЛ-СОТРУДНИК. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе. Графически степень связи N отображается "древообразной" линией, так это сделано на следующем рисунке.
Данный рисунок дополнительно иллюстрирует тот факт, что между двумя сущностями может быть определено несколько наборов связей.
Здесь также необходимо учитывать класс принадлежности сущностей. Каждый сотрудник должен работать в каком-либо отделе, но не каждый отдел (например, вновь сформированный) должен включать хотя бы одного сотрудника. Поэтому сущность "ОТДЕЛ" имеет обязательный, а сущность "СОТРУДНИК" необязательный классы принадлежности. Кардинальность бинарных связей степени N будем обозначать так:
Много к одному (N : 1 ). Эта связь аналогична отображению 1 : n. Предположим, что рассматриваемое нами предприятие строит свою деятельность на основании контрактов, заключаемых с заказчиками. Этот факт отображается в модели "сущность-связь" с помощью связи КОНТРАКТ-ЗАКАЗЧИК, объединяющей сущности КОНТРАКТ (НОМЕР, СРОК_ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК(НАИМЕНОВАНИЕ, АДРЕС). Так как с одним заказчиком может быть заключено более одного контракта, то связь КОНТРАКТ-ЗАКАЗЧИК между этими сущностями будет иметь степень N : 1.
В данном случае, по совершенно очевидным соображениям (каждый контракт заключен с конкретным заказчиком, а каждый заказчик имеет хотя бы один контракт, иначе он не был бы таковым), каждая сущность имеет обязательный класс принадлежности.
Многие ко многим (N : n). В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пусть на рассматриваемом нами предприятии для выполнения каждого контракта создается рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень N : n.
Если существование сущности x зависит от существования сущностиy, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" y - сильной).
В качестве примера рассмотрим связь между ранее описанными сущностями РАБОЧАЯ_ГРУППА и КОНТРАКТ. Рабочая группа создается только после того, как будет подписан контракт с заказчиком, и прекращает свое существование по выполнению контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой от сущности КОНТРАКТ. Зависимую сущность будем обозначать двойным прямоугольником, а ее связь с сильной сущностью линией со стрелкой:
Заметим, что кардинальность связи для сильной сущности всегда будет (1,1). Класс принадлежности и степень связи для зависимой сущности могут быть любыми. Предположим, например, что рассматриваемое нами предприятие пользуется несколькими банковскими кредитами, которые представляются набором сущностей: КРЕДИТ(НОМЕР_ДОГОВОРА, СУММА, СРОК_ПОГАШЕНИЯ, БАНК). По каждому кредиту должны осуществляться выплаты процентов и платежи в счет его погашения. Этот факт представляется набором сущностей ПЛАТЕЖ(ДАТА, СУММА) и набором связей "осуществляется по". В том случае, когда получение запланированного кредита отменяется, информация о нем должна быть удалена из базы данных. Соответственно, должны быть удалены и все сведения о плановых платежах по этому кредиту. Таким образом, сущность ПЛАТЕЖ зависит от сущности КРЕДИТ.
Похожие статьи
-
2.1 Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания...
-
Даталогическое проектирование - Банки и базы данных. Системы управления базами данных
Даталогической моделью БД называется модель логического уровня, построенная в рамках конкретной СУБД, в среде которой проектируется БД. Описание...
-
Настоящий курсовой проект предназначен для практического освоения проектирования реляционных баз данных (БД). В работе используется трехуровневый подход...
-
Описание предметной области ООО ИСК "Волгастройинвест" является официальным представителем ряда отечественных и зарубежных фирм, предлагающих на...
-
Уровни и типы моделей БД - Банки и базы данных. Системы управления базами данных
Любая БД отражает информацию об определенной предметной области. В зависимости от уровня абстракции, на котором представляется предметная область,...
-
Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели...
-
Построение ER диаграмм - Модернизация структуры базы данных на основе анализа требований предприятия
При построении моделей информационных систем важнейшей методикой является ER-моделирование или построение диаграмм сущность-связь. Сущность представляет...
-
Основные термины теории баз данных - БД (База данных) - совокупность специальным образом организованных данных, хранимых в памяти вычислительной системы...
-
Инфологическое моделирование применяется на втором этапе проектирования БД, то есть после системного анализа предметной области. Это построение...
-
Модель данных - Модели серверов баз данных
Модель данных - это множество правил, посредством которых производится создание структуры данных в базе данных, производятся операции над данными, а...
-
Связи между сущностями - Инфологическая модель базы данных: стройматериалы
Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных....
-
Разработка концептуальной модели базы данных При проектировании программ выясняются запросы и пожелания клиента и определяется возможный подход к решению...
-
Описание предметной области и структуры онлайн заявки на оказание услуг АСБ "Беларусбанк" Необходимо разработать базу данных для автоматизации онлайн...
-
Этапы проектирования и создания БД - Система управления базами данных
При разработке БД можно выделить следующие этапы работы. I этап. Постановка задачи. На этом этапе формируется задание по созданию БД. В нем подробно...
-
Общие понятия и определения баз данных Данные содержат различные события или сущности. Для работы с данными были созданы различные информационные...
-
ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ ИМД основана на понятии деревьев, состоящих из вершин и ребер. Вершине дерева ставится в соответствие совокупности атрибутов...
-
ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ База данных как основа информационного обеспечения В состав информационного, программного и математического обеспечения...
-
Логический уровень описания базы данных (логическая модель) отражает логические связи между таблицами. Логическая модель базы данных "Прокат автомобилей"...
-
Основные понятия распределенных баз данных Распределение баз данных - набор логических связанных между собой разделяемых данных (и их описаний), которые...
-
Объектно-ориентированное программирование (ООП) является парадигмой программирования, которая представляет понятия, как "объекты", которые имеют поля...
-
Распределенные базы данных - Теоретические основы информационных технологий
Системы распределенных вычислений появляются, прежде всего, по той причине, что в крупных автоматизированных информационных системах, построенных на...
-
Система управления базами данных - Модели серверов баз данных
Система управления базами данных (СУБД) - это приложение, посредством которого осуществляется обработка базы данных пользователем или группой...
-
Возрастающая сложность современных автоматизированных систем управления и повышение требовательности к ним обуславливает применение эффективных...
-
Еще недавно люди хранили свои записи на бумаге в непонятном и неструктурированном виде, поэтому возможности доступа к информации были очень плохие. В...
-
Теоретические предпосылки исследования Системы поддержки принятия решений Системы поддержки принятия решений (СППР), представляют собой приложения узкого...
-
При работе над проектом разрабатывались два основных компонента системы: база данных (далее - БД) и интерфейс клиентского приложения. Затем необходимо...
-
Этапы проектирования базы данных - Автоматизация процесса работы руководства ООО "Сервис партнер"
Основная цель проектирования БД заключается в том, чтобы обеспечить пользователя более точными данными, полностью удовлетворяющими их информационные...
-
Разработка логической модели АИС - Проектирование автоматизированной информационной системы
Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки...
-
Организация парольной защиты - Проектирование и разработка базы данных "Прокат автомобилей"
По мере того как деятельность организаций все больше зависит от компьютерных информационных технологий, проблемы защиты баз данных становятся все более...
-
Каждая СУБД имеет особенности в представлении структуры таблиц, связей, определении типов данных и т. д. которую необходимо учитывать при проектировании....
-
Обоснование выбора СУБД База данных - это совокупность сведений о реальных объектах, процессах, событиях или явлениях, относящихся к определенной теме...
-
Инфологические и даталогические модели данных - Теория экономических информационных систем
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о: -...
-
Инфологическое моделирование - Банки и базы данных. Системы управления базами данных
Инфологическое проектирование является вторым этапом проектирования БД, который следует непосредственно после анализа предметной области. Эта стадия...
-
Модели транзакций - Банки и базы данных. Системы управления базами данных
Под транзакциями понимаются действия, производимые над базой данных и переводящие ее из одного согласованного состояния в другое согласованное состояние....
-
Основным компонентом АРМ является база данных (БД). Использование БД является эффективным средством разработки и поддержки информационного обеспечения...
-
Разработка концептуальной модели АИС - Проектирование автоматизированной информационной системы
Любая деятельность компании отражается в документах, и, чтобы улучшить качество рабочих бизнес-процессов, необходимо улучшить документооборот, т. е....
-
Сетевая модель данных, Реляционная модель данных - Система управления базами данных
Отличие сетевой структуры от иерархической заключается в том, что каждый элемент в сетевой структуре может быть связан с любым другим элементом (рис. 8)....
-
Информационно-логические модели данных, Иерархическая модель - Система управления базами данных
Иерархическая модель Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Графическим способом...
-
Жизненный цикл КИС. Модели жизненного цикла КИС: каскадная, спиральная Понятие жизненного цикла программного обеспечения (ЖЦ ПО) является одним из...
-
Анализ предметной области позволяет выявить пять сущностей: Сущность: Растения для сада (наименование растения; вид; высота; время цветения; отношение к...
Проектирование модели данных - Основы проектирования баз данных