Ответы Основные понятия база данных и информационная система

image

CHIP расскажет, как начать работу с таблицей данных в Access и создать первичный ключ.

image

В базе данных каждая таблица может содержать только один первичный ключ. Он задается как характеристика записи в пределах таблицы.

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

Создание базы данных MS Access. В меню «Конструктор» вы можете задать первичный ключ к базе данных

Чтобы добавить первичный ключ к определенной строке, нажмите правой кнопкой мыши и выберите пункт «Ключевое поле». Первичный ключ может быть только один, поэтому Access автоматически удалит предыдущее ключевое поле из таблицы.

Фото: компании-производители

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

Естественные Ключи

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

  • Уникальные значения: первичный ключ должен уникально идентифицировать каждую строку в таблице.
  • Неинтеллектуальный: первичный ключ не должен иметь смыслового содержания. Другими словами, он не должен описывать характеристики сущности. Идентификатор клиента 398237 обычно более предпочтителен по сравнению с Майкл Дж. Малоун.
  • Неизменяемость во времени: значение первичного ключа никогда не должно меняться. Изменение значения первичного ключа означает, что Вы меняете идентичность сущности, что не имеет смысла. Неинтеллектуальные ключи предпочтительны, поскольку они с меньшей вероятностью подвержены изменениям.
  • Одноатрибутность: первичный ключ должен состоять из минимально возможного числа атрибутов. Желательно иметь одноатрибутные первичные ключи, поскольку с ними легче работать в приложениях, и они упрощают создание внешних ключей.
  • Числовой: легче управлять уникальными значениями, если они являются числовыми. Большинство систем базы данных имеют внутренние процедуры, которые поддерживают автоинкрементируемые атрибуты для первичных ключей. Хотя эти средства полезны, не используйте их бездумно.

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

Суррогатные ключи

Когда естественный ключ не существует или когда естественный ключ неудобен, самое время рассмотреть вариант использования суррогатного ключа (называемого также синтетическим ключом) для уникальной идентификации объектов. Суррогатный первичный ключ — обычно числовой одноатрибутный ключ, который часто автоматически генерируется системой баз данных. Пока некоторые администраторы баз данных продолжают обсуждать правомерность их использования, суррогатные первичные ключи повсеместно используются на практике.Суррогатный ключ сам по себе не несет никакого смысла. Т.е. в него не заложено никакого семантического значения. Единственная цель суррогатного ключа состоит в том, чтобы уникально идентифицировать объекты, и упрощать запись таких реляционных операций как соединения и фильтрация. Это единственное уникальное значение, которое никогда не должно изменяться (потому что его единственное назначение — идентифицировать сущность). Таким образом, это — идеальный первичный ключ.Поскольку суррогатные ключи всегда состоят из единственного атрибута, они могут упростить бизнес-логику. Если имя столбца первичного ключа таблицы может быть получено из названия таблицы, то, например, может использоваться генератор кода для построения примитивного слоя абстракции базы данных. Такие ключи, в комбинации с названием таблицы, действуют как глобальный уникальный идентификатор времени исполнения. Этот идентификатор может использоваться для построения сложных механизмов кэширования, облегчает загрузку по требованию (lazy-loading), и упрощает преобразование в последовательную форму.

Заключение

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

Рис. 1.1.Структурареляционной таблицы Abonent

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

Каждый вертикальный столбец таблицы представляет совокупность значений конкретного атрибута объекта. Например, в столбце AccountCD содержатся уникальные номера лицевых счетов абонентов. В столбце Phone содержатся номера телефонов абонентов.

На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей абонента Конюхова В. С., в столбце Fio содержится значение ‘Конюхов В.С.’. В столбце AccountCD той же строки содержится значение ‘015527’, которое является номером лицевого счета абонента с ФИО Конюхов В. С.

Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце Fio содержатся только слова, а в столбце StreetCD содержатся целые числа, представляющие идентификаторы улиц. В реляционной модели данных общая совокупность значений, из которой берутся действительные значения для определенных атрибутов (столбцов), называется доменом [1]. Доменом столбца Fio, например, является множество фамилий, имен и отчеств (ФИО) абонентов. Каждый столбец всегда определяется на одном домене.

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

В учебной базе данных определены следующие домены:

§ Boollean (Логический): SMALLINT. Поля, определяемые на этом домене, могут принимать только целочисленные значения, равные 0 или 1. Это достигается наложением в домене условия проверки (CHECK) на принимаемые этим доменом значения.

§ Money (Деньги): NUMERIC(15,2). Домен предназначен для определения в таблицах полей, хранящих денежные суммы.

§ PKField (Поле ПК): INTEGER. Домен предназначен для определения первичных и внешних ключей таблиц. Ограничение обязательности данных (NOT NULL) на этот домен не наложено. Оно накладывается при объявлении первичного ключа таблицы. Это сделано для того, чтобы можно было определить внешний ключ на этом домене без условия NOT NULL.

§ TMonth (Месяц): SMALLINT. Домен предназначен для определения в таблицах полей, содержащих номера месяцев. Целочисленные значения в таком поле могут находиться в диапазоне 1…12.

§ TYear (Год): SMALLINT. Домен предназначен для определения полей, содержащих номер года. Целочисленные значения могут находиться в диапазоне 1990…2100.

Поскольку строки в реляционной таблице не упорядочены, то нельзя выбрать строку по ее номеру в таблице. В таблице нет «первой», «последней» или «тринадцатой» строки. Тогда каким же образом можно указать в таблице конкретную строку, например строку для абонента с ФИО Аксенов С.А.?

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

В реляционной базе данных в каждой таблице есть 1 или несколько столбцов, значения в которых во всех строках разные. Этот столбец (столбцы) называется первичным ключом таблицы.

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

Вернемся к рассмотрению таблицы Abonent учебной базы данных (рис. 1.1). На первый взгляд, первичным ключом таблицы Abonent могут служить и столбец AccountCD, и столбец Fio. Однако в случае если будут зарегистрированы 2 абонента с одинаковыми ФИО, то столбец Fio больше не сможет исполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как уникальный номер лицевого счета абонента (AccountCD в таблице Abonent), идентификатор улицы (StreetCD в таблице Street) и т. д.

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

Если первичный ключ представляет собой комбинацию столбцов, то такой первичный ключ называется составным.

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



Эта статья написана Бриттни Паркер, писателем из Girls Write Tech, которая специализируется на написании технических материалов. Они стремятся побудить больше женщин-разработчиков делиться своими знаниями.

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

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

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

Сегодня это руководство познакомит вас с внешними ключами и покажет, как их использовать в SQL.

Содержание

Что такое внешний ключ в базе данных?

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

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

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

Столбец, действующий как внешний ключ, должен иметь соответствующее значение в связанной таблице. Это создает ссылочную целостность.

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

Скажем, у нас есть две таблицы с именами customerи order. Мы можем использовать внешний ключ для создания связи между ними. В ordersтаблице мы создаем ключ, который ссылается на клиента (т.е. CUSTOMER_ID) в другой таблице.

В CUSTOMER_IDтаблице заказов становится внешним ключом, который ссылается на родительский или первичный ключи в таблице клиентов.

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

Если мы попытаемся ввести CUSTOMER_IDданные, которых нет в таблице клиентов, мы нарушим целостность ссылочных полномочий таблицы.

Ограничение FK

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

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

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

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

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

  • Используется CONSTRAINTзначение символа, и оно должно быть уникальным в базе данных.
  • Для таблиц InnoDB имя ограничения создается автоматически, если условие символа ограничения не определено.
  • Для таблиц NDB используется FOREIGN KEY index_nameзначение или автоматически создается имя ограничения.

Внешний ключ против первичного ключа

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

Внешние ключи используются больше как ссылка, чем как уникальный идентификатор конкретной строки или записи.

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

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

Внешний ключ против составного ключа

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

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

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

Ссылочные действия внешнего ключа

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

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

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

Совет: передовой опыт указывает на использование NOT NULLограничения при создании внешних ключей для поддержания структурной целостности базы данных.

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

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

Внешние ключи в SQL и MySQL

Давайте посмотрим на синтаксис с использованием SQL и MySQL. В следующем примере создается FOREIGN KEY в столбце «PersonID».

Узнайте больше о различных типах баз данных здесь

MySQL

CREATE TABLE Orders (      OrderID int NOT NULL,      OrderNumber int NOT NULL,      PersonID int,   PRIMARY KEY (OrderID),   FOREIGN KEY (PersonID) REFERENCES Persons(PersonID)  );

SQL Server

CREATE TABLE Orders (      OrderID int NOT NULL PRIMARY KEY,      OrderNumber int NOT NULL,      PersonID int FOREIGN KEY REFERENCES Persons(PersonID)  );

Следующий синтаксис позволяет нам назвать ограничение FOREIGN KEY:

CREATE TABLE Orders (      OrderID int NOT NULL,      OrderNumber int NOT NULL,      PersonID int,   PRIMARY KEY (OrderID),   CONSTRAINT FK_PersonOrder FOREIGN KEY (PersonID)   REFERENCES Persons(PersonID)  );

Реальный пример SQL

А теперь давайте уточним. Ниже Actorsтаблица является таблицей, на которую ссылаются, и называется родительской таблицей. Здесь справочная таблица DigitalAssetsявляется дочерней таблицей.

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

В нашем примере мы изменяем наш DigitalAssetsи устанавливаем ActorIDстолбец как внешний ключ следующим образом:

ALTER TABLE DigitalAssets  ADD FOREIGN KEY (ActorId)  REFERENCES Actors(Id);

Теперь, если мы добавим в DigitalAssetsтаблицу строку с идентификатором актера, которого нет в Actorsтаблице, появится сообщение об ошибке:

INSERT INTO DigitalAssets  VALUES ("www.dummy.url", "instagram", "2030-01-01 00:00:00", 100);

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

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

2.4. Системы управления базами данных и экспертные системы

2.4.1. Основные понятия Баз данных Access 2003

Развития вычислительной техники осуществлялось по двум основным направлениям:

  • применение вычислительной техники для выполнения численных расчетов;
  • использование средств вычислительной техники в информационных системах.

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

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

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

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

Существуют 4 основные модели данных – списки (плоские таблицы), реляционные базы данных, иерархические и сетевые структуры.

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

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

Основные понятия реляционных БД: нормализация, связи и ключи

1. Принципы нормализации:

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

2. Виды логической связи.

Связь устанавливается между двумя общими полями (столбцами) двух таблиц. Существуют связи с отношением «один-к-одному», «один-ко-многим» и «многие-ко-многим».

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

Тип отношения в создаваемой связи зависит от способа определения связываемых полей:

  1. Отношение «один-ко-многим» создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса.
  2. Отношение «один-к-одному» создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.
  3. Отношение «многие-ко-многим» фактически является двумя отношениями «один-ко-многим» с третьей таблицей, первичный ключ которой состоит из полей внешнего ключа двух других таблиц

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

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

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

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

Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.

Поле счетчика (Тип данных «Счетчик»). Тип данных поля в базе данных, в котором для каждой добавляемой в таблицу записи в поле автоматически заносится уникальное числовое значение.

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

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

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

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

Программы, которые предназначены для структурирования информации, размещения ее в таблицах и манипулирования данными называются системами управления базами данных (СУБД). Другими словами СУБД предназначены как для создания и ведения базы данных, так и для доступа к данным. В настоящее время насчитывается более 50 типов СУБД для персональных компьютеров. К наиболее распространенным типам СУБД относятся: MS SQL Server, Oracle, Informix, Sybase, MS Access  и т. д.

Создание БД. Этапы проектирования

Создание БД начинается с проектирования.

Этапы проектирования БД:

  • исследование предметной области;
  • анализ данных (сущностей и их атрибутов);
  • определение отношений между сущностями и определение первичных и вторичных (внешних) ключей.

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

К базовым понятиями модели БД «сущность – связь» относятся: сущности, связи между ними и их атрибуты (свойства).

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

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

Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения  между частями БД (в реляционной БД – это соединение между записями таблиц).

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

Рассмотрим предметную область: Деканат (Успеваемость студентов).

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

Основными предметно-значимыми сущностями БД «Деканат» являются: Студенты, Группы студентов, Дисциплины, Успеваемость.

Основные предметно-значимые атрибуты сущностей:

  • студенты – фамилия, имя, отчество, пол, дата и место рождения, группа студентов;
  • группы студентов – название, курс, семестр;
  • дисциплины – название, количество часов;
  • успеваемость – оценка, вид контроля.

Основные требования к функциям БД:

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

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

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

На основе вышеизложенного составляем модель сущность – связь для БД «Деканат»

Рис. 1.

— стрелка является  условным обозначением связи: один – ко – многим.

Для создания БД необходимо применить одну из известных СУБД, например СУБД Access.

Далее>>>Тема: 2.4.2. Система управления базами данных Mіcrosoft Access 2003 и ее основные возможности

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
А как считаете Вы?
Напишите в комментариях, что вы думаете – согласны
ли со статьей или есть что добавить?
Добавить комментарий