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

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

Записи – горизонтальные строки данных в таблицах.

Запрос – способ получения данных из таблицы в соответствии с заданным критерием. По запросам можно просматривать поля сразу нескольких таблиц или элементы одной записи.

Макросы – средство автоматизации работы с базами данных в MS Access, позволяющее автоматически выполнять последовательность часто повторяемых действий.

Модули – объекты для хранения и использования программ на языке Visual Basic for Application (VBA), предназначенные для расширения возможностей MS Access, а также других программ пакета MS Office.

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

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

Поля – вертикальные столбцы данных в таблицах. Каждое поле представляет собой элемент, зарезервированный для данных определенного типа.

Реляционная база данных – база данных из связанного набора таблиц.

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

Страницы доступа к данным ­– специальные веб-страницы, которые предоставляют удаленным пользователям сети Internet веб-интерфейс форм Access для доступа к базам данных.

Таблицы – информация, расположенная в строках и столбцах в табличной форме.

Формы – объекты, используемые для отображения таблиц или запросов в удобном для чтения, редактирования и ввода новых данных формате. В формах может отображаться информация из нескольких таблиц или запросов.

SQL (Structured Query Language) ­– язык структурированных запросов, специализированный язык для создания запросов.

Модель предметной области “Cущность-связь”

Модель “Сущность связь” (Entity-Relationship Model /ERM/, Entity-Relationship Diagram /ERD/) относится к семантическому моделированию, т. е. моделированию, опирающемуся на смысл используемых в модели данных. Первый вариант модели “Сущность связь” был предложен Питером Пин-Шэн Ченом в 1976 г. как метод проектирования баз данных.

За последние годы разработано большое количество вариантов этой модели пригодных как для разработки баз и хранилищ данных, так и анализа предметной области. Наиболее известными из указанных моделей являются: нотация Мартина (Information Engineering, IE), нотация Баркера, IDEF1, IDEF1X, нотация UML.

Рассмотрим основные понятия, используемые в модели “Сущность связь”.

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

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

Атрибуты сущности – это именованные характеристики, являющиеся свойствами сущности (ее параметрами).

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

Производные атрибуты – атрибуты, которые можно вычислить через другие атрибуты.

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

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

Реляционная модель данных – представление данных в виде связанных двумерных таблиц.

Первичный ключ (Primary Key /PK/, ключ сущности, идентификатор сущности) – это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для конкретного экземпляра сущности и позволяют однозначно выделить его из других экземпляров данной сущности.

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

Связь – это некоторая ассоциация между двумя и более сущностями. Связь между двумя сущностями – бинарная. Связь сущности самой с собой – рекурсивная. Связь, обычно, именуется в неопределенной глагольной форме, например, “Иметь”, ”Принадлежать”.

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

Физическая модель БД – модель построения ИС и СУБД на основе конкретной программной реализации.

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

Нотация Баркера

В настоящем параграфе рассмотрено построение и использование модели “Сущность связь” в нотации Баркера, отличающейся простотой и наглядностью.

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

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

Рисунок 3.5 - Обозначение сущности “Сотрудник” в нотации Баркера

Связи между сущностями обозначаются сплошными или пунктирными линиями. Различают три типа и две модальности связи (см. таблицу 3.1).

Таблица 3.1 – Связи между сущностями в нотации Баркера

Связь между двумя сущностями в словесной форме записывается следующим образом:

<Каждый экземпляр сущности 1> <Модальность связи> <Наименование связи> <Тип связи> <Экземпляр сущности 2>.

Аналогичную запись можно сделать, двигаясь от сущности 2 к сущности 1.

Рассмотрим поясняющий пример (см. рисунок 3.6).

Рисунок 3.6 – Пример связи между двумя сущностями

Каждый студент должен писать диплом под руководством одного преподавателя.

Каждый преподаватель может руководить несколькими студентами.

Рассмотрим методику разработки логической модели реляционной базы данных на основе модели “Сущность-связь”.

Порядок разработки содержит следующую последовательность действий:

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

2. Выбираются атрибуты сущностей, в том числе и ключевые атрибуты.

3. Описываются связи между сущностями модели. Результатом данного этапа является получение начальной модели “Сущность-связь”.

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

Рассмотрим пример преобразования связи “много ко многим”.

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

На рисунке 3.7 показана исходная диаграмма с двумя сущностями: Склад и Товар, со связью многие ко многим.

Рисунок 3.7 – Исходная диаграмма

На рисунке 3.8 для преобразования связи введена дополнительная сущность Товар на складе.

Рисунок 3.8 ­– Преобразованная диаграмма

Рассмотрим модель базы данных ИС_Учет_Успеваемости из лабораторной работы.

Рисунок 3.9 – Пример базы данных успеваемости студентов

Каждый студент может иметь несколько записей в электронном журнале.

Каждая запись в электронном журнале должна соответствовать одному студенту.

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

Каждая запись в электронном журнале должна соответствовать одной дисциплине.

Стандарт IDEF1X

Как и во всех других моделях, основанных на диаграммах “Сущность-связь”, основные элементы диаграммы IDEF1X, это сущности, атрибуты и связи.

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

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

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

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

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

По своей мощности идентифицирующая связь имеет тип “один ко многим”, много на стороне зависимой сущности.

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

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

На рисунке 3.10 показан пример определения зависимой сущности Заказ, через независимую сущность Клиент. В данном примере заказ принципиально не может существовать без клиента.

Рисунок 3.10 – Пример определения зависимой сущности

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

Рассмотрим пример, предположим, что сотрудник некой организации может как числится в каком-то отделе, так и не принадлежать ни какому отделу (см. рисунок 3.11).

Рисунок 3.11 – Пример неидентифицирующей связи между сущностями

Интересным примером неидентифицирующей связи является рекурсивная связь. В примере на рисунке 3.12 с помощью нерекурсивной связи задаются руководители сотрудника.

Рисунок 3.12 – Пример рекурсивной связи

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

В IDEF1X используются приведенные в таблице 3.2 обозначения мощности связи на стороне дочерней сущности.

Таблица 3.2 ­– Мощность связей

Наряду с идентифицирующими и неидентифицирующими связями в IDEF1X используются связи типа многие ко многим. Пример такой связи между сущностями показан на рисунке 3.13.

Связь многие ко многим является временным типом связи, используемой на начальной стадии анализа, в дальнейшем она преобразуется путем введения дополнительной сущности (см. рисунок 3.14).

Рассмотрим типы зависимых сущностей.

Характеристическая – связана только с одной родительской и характеризует ее (см., например, рисунок 3.10).

Рисунок 3.13 – Пример связи многие ко многим

Ассоциативная – связана с несколькими родительскими сущностями (см., например, рисунок 3.14).

Рисунок 3.14 – Пример разделения связи многие ко многим

Именующая – частный случай ассоциативной, не имеющая собственных атрибутов (только атрибуты родительских сущностей).

Категориальная – дочерняя сущность в иерархии наследования.

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

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

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

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

Рисунок 3.15 – Пример неполной категории

На рисунке 3.16 показан пример полной категории.

Рисунок 3.16 – Пример полной категории

Не нашли, что искали? Воспользуйтесь поиском по сайту: