код атрибута для разных сущностей должен быть уникальным
Уникальный идентификатор
Прежде чем переходить к следующему этапу нормализации, требуется применить к нашей таблице одно правило (оно же будет действовать для всех таблиц, которые мы создадим позднее).
У каждой сущности должен быть уникальный идентификатор, т.е. некоторый атрибут, имеющий следующие свойства:
Он уникален для каждого экземпляра сущности (т.е. во всех строках таблицы он не должен повторяться).
Для каждого экземпляра сущности он имеет значение в течение всего срока существования экземпляра в БД, причём это значение не меняется, пока экземпляр существует. Это означает, что данный столбец не может быть пустым; причём он заполняется в момент создания строки, и его значение не изменяется вплоть до удаления строки.
Например, название книги не может быть идентификатором. Вполне возможно появление двух книг с одинаковыми названиями. К тому же в названии книги может найтись опечатка, и его придётся подправить – а идентификатор не должен меняться.
Теоретически в качестве идентификатора можно выбрать даже несколько полей таблицы, при этом все вместе эти поля должны удовлетворять перечисленным выше требованиям. Так, вряд ли появятся две разные книги одного автора, одного названия и изданные в один год; поэтому из этих трёх полей можно бы сделать идентификатор. Но работать с ним было бы достаточно неудобно.
На ER-диаграммах названия идентифицирующих атрибутов обычно подчеркивают или помечают звездочкой. Иногда идентификаторы называют ключевыми полями или ключами.
(Интересно, что библиотекари тоже столкнулись с необходимостью такого идентифицирующего атрибута,. Поэтому каждая библиотечная книга имеет специальный “шифр” или “инфентарный номер”; он обычно подписывается на внутренней стороне обложки.)
Код атрибута для разных сущностей должен быть уникальным
Развитие вычислительной техники осуществлялось по двум основным направлениям:
Информационная система – это совокупность программно-аппаратных средств, способов и людей, которые обеспечивают сбор, хранение, обработку и выдачу информации для решения поставленных задач. На ранних стадиях использования информационных систем применялась файловая модель обработки. В дальнейшем в информационных системах стали применяться базы данных. Базы данных являются современной формой организации, хранения и доступа к информации. Примерами крупных информационных систем являются банковские системы, системы заказов железнодорожных билетов и т.д.
База данных – это интегрированная совокупность структурированных и взаимосвязанных данных, организованная по определенным правилам, которые предусматривают общие принципы описания, хранения и обработки данных. Обычно база данных создается для предметной области.
Предметная область – это часть реального мира, подлежащая изучению с целью создания базы данных для автоматизации процесса управления.
Наборы принципов, которые определяют организацию логической структуры хранения данных в базе, называются моделями данных.
Существуют 4 основные модели данных – списки (плоские таблицы), реляционные базы данных, иерархические и сетевые структуры.
В течение многих лет преимущественно использовались плоские таблицы (плоские БД) типа списков в Excel. В настоящее время наибольшее распространение при разработке БД получили реляционные модели данных. Реляционная модель данных является совокупностью простейших двумерных таблиц – отношений (англ. relation),т.е. простейшая двумерная таблица определяется как отношение (множество однотипных записей объединенных одной темой).
От термина relation (отношение) происходит название реляционная модель данных. В реляционных БД используется несколько двумерных таблиц, в которых строки называются записями, а столбцы полями, между записями которых устанавливаются связи. Этот способ организации данных позволяет данные (записи) в одной таблице связывать с данными (записями) в других таблицах через уникальные идентификаторы (ключи) или ключевые поля.
Основные понятия реляционных БД: нормализация, связи и ключи
1. Принципы нормализации:
2. Виды логической связи.
Связь устанавливается между двумя общими полями (столбцами) двух таблиц. Существуют связи с отношением «один-к-одному», «один-ко-многим» и «многие-ко-многим».
Отношения, которые могут существовать между записями двух таблиц:
Тип отношения в создаваемой связи зависит от способа определения связываемых полей:
3. Ключи. Ключ – это столбец (может быть несколько столбцов), добавляемый к таблице и позволяющий установить связь с записями в другой таблице. Существуют ключи двух типов: первичные и вторичные или внешние.
Первичный ключ – это одно или несколько полей (столбцов), комбинация значений которых однозначно определяет каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Первичный ключ используется для связывания таблицы с внешними ключами в других таблицах.
Из двух логически связанных таблиц одну называют таблицей первичного ключа или главной таблицей, а другую таблицей вторичного (внешнего) ключа или подчиненной таблицей. СУБД позволяют сопоставить родственные записи из обеих таблиц и совместно вывести их в форме, отчете или запросе.
Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.
Поле счетчика (Тип данных «Счетчик»). Тип данных поля в базе данных, в котором для каждой добавляемой в таблицу записи в поле автоматически заносится уникальное числовое значение.
Простой ключ. Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как первичный ключ. В качестве ключа можно определить любое поле, содержащее данные, если это поле не содержит повторяющиеся значения или значения Null.
Необходимо еще раз отметить, что в поле первичного ключа должны быть только уникальные значения в каждой строке таблицы, т.е. совпадение не допускается, а в поле вторичного или внешнего ключа совпадение значений в строках таблицы допускается.
Если возникают затруднения с выбором подходящего типа первичного ключа, то в качеcтве ключа целесообразно выбрать поле счетчика.
Программы, которые предназначены для структурирования информации, размещения ее в таблицах и манипулирования данными называются системами управления базами данных ( СУБД). Другими словами СУБД предназначены как для создания и ведения базы данных, так и для доступа к данным. В настоящее время насчитывается более 50 типов СУБД для персональных компьютеров. К наиболее распространенным типам СУБД относятся: MS SQL Server, Oracle, Informix, Sybase, MS Access и т. д.
Создание БД. Этапы проектирования
Создание БД начинается с проектирования.
Этапы проектирования БД:
В процессе проектирования определяется структура реляционной БД (состав таблиц, их структура и логические связи). Структура таблицы определяется составом столбцов, типом данных и размерами столбцов, ключами таблицы.
К базовым понятиями модели БД «сущность – связь» относятся: сущности, связи между ними и их атрибуты (свойства).
Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. Например, для сущности студент могут быть использованы следующие атрибуты: фамилия, имя, отчество, дата и место рождения, паспортные данные и т.д. В реляционной БД атрибуты хранятся в полях таблиц.
Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения между частями БД (в реляционной БД – это соединение между записями таблиц).
Рассмотрим предметную область: Деканат (Успеваемость студентов).
В БД «Деканат» должны храниться данные о студентах, группах студентов, об оценках студентов по различным дисциплинам, о преподавателях, о стипендиях и т.д. Ограничимся данными о студентах, группах студентов и об оценках студентов по различным дисциплинам. Определим сущности, атрибуты сущностей и основные требования к функциям БД с ограниченными данными.
Основными предметно-значимыми сущностями БД «Деканат» являются: Студенты, Группы студентов, Дисциплины, Успеваемость.
Основные предметно-значимые атрибуты сущностей:
Основные требования к функциям БД:
Из анализа данных предметной области следует, что каждой сущности необходимо назначить простейшую двумерную таблицу (отношения). Далее необходимо установить логические связи между таблицами. Между таблицами Студенты и Успеваемость необходимо установить такую связь, чтобы каждой записи из таблицы Студенты соответствовало несколько записей в таблице Успеваемость, т.е. один – ко – многим, так как у каждого студента может быть несколько оценок.
Логическая связь между сущностями Группы – Студенты определена как один – ко – многим исходя из того, что в группе имеется много студентов, а каждый студент входит в состав одной группе. Логическая связь между сущностями Дисциплины – Успеваемость определена как один – ко – многим, потому что по каждой дисциплине может быть поставлено несколько оценок различным студентам.
На основе вышеизложенного составляем модель сущность – связь для БД «Деканат»
Для создания БД необходимо применить одну из известных СУБД, например СУБД Access.
Код атрибута для разных сущностей должен быть уникальным
Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной или нескольких локальных моделей, которые относительно легко могут быть отображены в любую схему баз данных.
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Для обеспечения связи между сущностями используются понятия ключей :
Первичный (главный) ключ должен обладать следующими свойствами:
Под методологией понимают дисциплину проектирования:
Методология информационного моделирования IDEF1X основана на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме.
В методологии IDEF1X принята следующая терминология:
В методологии принята система простых графических символов для отражения понятий:
Рис. П.1.1 Обозначения для a) независимой и b) зависимой сущностей модели
Каждой сущности присваивается уникальное имя (существительное в единственном числе) и номер, разделенные косой чертой “/” и помещаемые над блоком.
Для описания связи указываются следующие элементы:
В IDEF1X могут быть выражены следующие мощности связей:
Связь изображается линией, проводимой между сущностями, с точкой но конце линии у сущности-потомка (рис. П.2).
Рис. П.2.2. Графическое изображение мощности связи
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный (главный, Primary Key) ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.
Рис. П.1.3. Пример, показывающий неидентифицирующую связь
Пример идентифицирующей связи показан на рис. П.1.1.
В идентифицирующей связи первичный ключ сущности/1 переходит в качестве FK в сущность /3 и размещается в области главного ключа.
Ниже на рис. П.1.4. показан пример построения ER-модели по стандарту IDEF1X.
Рис.П.1.4. Пример построения ERD
Ниже, в табл.1 приведен пример описания физической модели данных на основе диаграммы отношения сущностей, представленной на рис. П.1.4.
Атрибуты (службы Master Data Services)
Связь атрибутов с другими объектами модели
Атрибут можно представить как столбец таблицы сущности. Значение атрибута — это значение, описывающее определенный элемент.
При создании сущности, содержащей множество атрибутов, можно организовать атрибуты в группы. Дополнительные сведения см. в разделе Группы атрибутов (службы Master Data Services).
Обязательные атрибуты
При создании сущности атрибуты «Имя» и «Код» создаются автоматически. Атрибут «Код» должен иметь значение, уникальное внутри сущности. Удалить атрибуты «Имя» и «Код» нельзя.
Типы атрибутов
Существует три типа атрибутов.
Атрибуты свободной формы, допускающие свободный ввод текста, чисел, дат или ссылок.
Атрибуты на основе домена, заполненные сущностями. Дополнительные сведения см. в разделе Атрибуты на основе домена (службы Master Data Services).
Файловые атрибуты, используемые для хранения файлов, документов или изображений. Атрибуты файлов помогают обеспечивать согласованность данных, требуя наличия у файла определенного расширения. Атрибуты файлов не могут гарантированно запретить злоумышленнику передать файл другого типа.
Числовые атрибуты в свободной форме
По умолчанию значение SqlDouble содержит 15 знаков после запятой, хотя для внутренних целей поддерживается до 17 знаков. Точность числа с плавающей запятой может иметь следующие эффекты.
Два числа с плавающей запятой, которые могут казаться равными при определенной точности, на самом деле отличаются, поскольку их менее значащие цифры различаются.
Математическая операция или сравнение, в которой используется число с плавающей запятой, может выдавать разные результаты при использовании десятичного числа, поскольку число с плавающей запятой может не совсем точно соответствовать десятичному числу.
Примеры атрибутов
В следующем примере сущность имеет атрибуты: Name, Code, Subcategory, StandardCost, ListPrice и FilePhoto. Эти атрибуты описывают элементы. Каждый элемент представлен отдельной строкой значений атрибута.
В следующем примере сущность Product содержит:
атрибуты в свободной форме Name, Code, StandardCost и ListPrice;
атрибут на основе домена Subcategory;
атрибут файла FilePhoto.
Сущность Subcategory используется в качестве атрибута на основе домена сущности Product. Сущность Category используется в качестве атрибута на основе домена сущности Subcategory. Как и сущность Product, сущности Category и Subcategory по умолчанию содержат атрибуты Name и Code.
Код атрибута для разных сущностей должен быть уникальным
Мы опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей. Данная глава является скорее иллюстрацией методов семантического моделирования, чем полноценным введением в эту область.
Основные понятия ER-диаграмм
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.
Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник», «Накладная».
Каждая сущность в модели изображается в виде прямоугольника с наименованием:
Например, представителем сущности «Сотрудник» может быть «Сотрудник Иванов».
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность:
Сущность может иметь несколько различных ключей.
Ключевые атрибуты изображаются на диаграмме подчеркиванием:
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Графически связь изображается линией, соединяющей две сущности:
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: «иметь», «принадлежать» и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи:
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностей связи:
Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Связь может иметь разную модальность с разных концов (как на Рис. 4).
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 читается так:
Слева направо: «каждый сотрудник может иметь несколько детей».
Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».
Пример разработки простой ER-модели
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п.
Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.
Куда поместить сущности «Накладная» и «Склад» и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями «Покупатель» и «Товар»? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:
Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введем дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Теперь можно внести все это в диаграмму:
Концептуальные и физические ER-модели
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведенной на Рис. 9 может выглядеть, например, следующим образом:
Легко заметить, что полученные таблицы сразу находятся в 3НФ.
Выводы
Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование.
Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей.
Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.
При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.
В данной главе, являющейся иллюстрацией к методам ER-моделирования, не рассмотрены более сложные аспекты построения диаграмм, такие как подтипы, роли, исключающие связи, непереносимые связи, идентифицирующие связи и т.п.