НОВЫЙ КУРС БД 2013

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

Обычная логика двухзначна, то есть приписывает высказываниям только два возможных значения: истинно оно или ложно. Существуют также многозначные логики (Яна Лукасевича, С. Клини и др.). Простейшим примером является трехзначная логика, где еще 1 значением является значение – «неопределенности» или «неизвестности». Данный вид логики также используется в базах данных реляционного типа и для обозначения «неопределенного» значения используется NULL. Поговорим подробнее о действиях над выражениями, содержащими Null-значения. Каждое новое вхождение Null-значения рассматривается как независимое, и каждый раз Null-значения воспринимаются как различные неизвестные значения. Этим Null-значения кардинально отличаются от всех остальных типов данных, ведь мы знаем, что обо всех пройденных ранее величинах и их типах с уверенностью можно было говорить, что они равны или не равны друг другу.

Итак, мы видим, что Null-значения не являются значениями переменных в обычном смысле этого слова. Поэтому становится невозможным сравнивать значения переменных или выражения, содержащие Null-значения, поскольку в результате мы будем получать не логические значения True или False, а Null-значения, как в следующих примерах:

(x < Null); (x <= Null); (x = Null); (x ? Null); (x > Null);

Поэтому по аналогии с пустыми значениями для проверки выражения на Null-значения необходимо использовать специальный предикат: IsNull (<выражение>).

Основные операции над логическими высказываниями

Отрицание логического высказывания (¯¯¯) — логическое высказывание, принимающее значение «истинно», если исходное высказывание ложно, и наоборот.

Конъюнкция двух логических высказываний (&) — логическое высказывание, истинное только тогда, когда они одновременно истинны.

Дизъюнкция двух логических высказываний (or) — логическое высказывание, истинное только тогда, когда хотя бы одно из них истинно.

Импликация двух логических высказываний (If … then …)A и B — логическое высказывание, ложное только тогда, когда B ложно, а A истинно.

Равносильность (эквивалентность) двух логических высказываний — логическое высказывание, истинное только тогда, когда они одновременно истинны или ложны.

Таблицы истинности:

11

1.3Базы данных и СУБД

1.3.1Основные понятия

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

БД - совокупность данных систематизированных специальным способом, который позволяет осуществлять хранении, поиск и обработку этих данных.

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

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

Основные функции СУБД

журнализация изменений, резервное копирование и восстановление базы данных после сбоев;

разграничение доступа к данным по ролям и пользователям;

поддержка языков БД (язык определения и манипулирования данными).

Основные компоненты СУБД

ядро, которое отвечает за управление данными во внешней и оперативной памяти, и журнализацию,

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

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

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

1.3.2 Виды СУБД

1.по типу распределнности:

Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

2.по способу доступа к БД  Файл-серверные

Вфайл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость централизованного управления; затруднённость обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях. На данный момент файл-серверная технология в реальных проектах не применяется. Примеры: MS Access, Paradox, FoxPro.

 Клиент-серверные

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

Примеры: MS SQL Server, MySQL, Oracle, Firebird.

12

Существует также понятие банка данных:

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

Итак, мы рассмотрели основные понятия, используемые в «технических кругах», познакомились с понятием БД, СУБД рассмотрели их типы и свойства, а также БнД. Перейдем теперь к видам БД.

1.3.3Виды баз данных

1.Иерархические – иерархические базы данных могут быть представлены как дерево,

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

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

Наиболее распространенными в практике являются реляционные базы данных. Были придуманы около 40 лет назад Эдгаром Коддом, когда он работал в IBM.

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

Теперь рассмотрим, что такое реляционная модель данных, что такое модель данных, что такое абстракция и модель вообще:

Модель – приблизительная копия реального объекта или явления, отражающая его существенные свойства для данного исследования. Пример: масштабная модель автомобиля, здания и др.

Абстракция – затенение (отбрасывание) некоторых свойств и связей объекта или явления с целью выделения необходимых (существенных) закономерностей и свойств исследуемого объекта или явления.

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

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

Разобравшись с понятиями моделей, перейдем к понятию модели данных. Что касается модели данных, то здесь все сложнее. Содержание понятия модели данных постоянно менялось с 70-х годов, причем менялось кардинально. А до 70-х годов данное понятие использовалось

13

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

Материал из ВикипЕдии (источник Дейт К. Дж. Введение в системы баз данных. 8-е изд. М.: «Вильямс», 2006.):

Модель данных — это абстрактное, самодостаточное1, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных.

Вообще говоря, данное определение, на мой взгляд, достаточно запутанно и не очень корректно, поскольку сама трактовка «абстрактное, самодостаточное определение объектов» сложно для восприятия и понимания. На мой взгляд, целесообразно использовать следующее определение модели данных выведенное мной после прочтения статьи «Абстракции и модели в системах баз данных» М. Р.Когаловский 01.08.1998. http://www.osp.ru/dbms/1998/04_05/07.htm:

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

средств манипулирования свойствами объектов и связями между объектами.

Т.е. это совокупность того, что описано (в смысле какие свойства объекта затронуты), как описано (в смысле способа представления этих свойств) и какие методы определены для манипуляции объектами и их свойствами. Я не претендую на 100% полноту данного определения и не навязываю его, однако, на мой взгляд, оно наиболее понятно отражает смысл данного понятия. Далее мы перейдем, непосредственно к рассмотрению реляционной модели данных.

Реляционная модель данных (РМД) – прикладная теория проектирования БД, основой в которой являются отношения (relation) между объектами (явлениями), а сами объекты (процессы) являются абстрактными моделями. При решении задач проектирования БД, при помощи РМД, используются такие разделы математики, как «Теория Множеств» и «Логика». Кроме того, в РМД также включена теория «Нормализации». Данные разделы математики мы рассмотрим чуть позже, а пока остановимся более подробно на РМД.

Как уже было написано выше любая модель данных (в том числе и реляционная) включает, по меньшей мере, 3 аспекта: как описано, что описано и какие методы манипуляции этим «что» определены. В рамках теории построения БД данные аспекты приобрели следующий вид:

1)аспект структуры: (как и что) методы описания типов и логических структур данных в БД;

2)аспект манипуляции: (методы) методы манипулирования данными;

3)аспект целостности: (методы) методы описания и поддержки целостности базы данных.

РМД с точки зрения этих трех аспектов выглядит так:

1)Аспект структуры — данные хранятся в виде таблиц и отношений между ними;

2)Аспект манипуляции — РМД поддерживает операторы манипулирования отношениями (теория множеств, реляционная алгебра, реляционное исчисление).

3)Аспект целостности — отношения (таблицы) отвечают определенным условиям целостности (уровень типа данных, уровень отношений и уровень БД).

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

1 Самодостаточный – достаточно значительный сам по себе, имеющий самостоятельную ценность либо способный обходиться собственными возможностями

2	рикладной – имеющий чисто практическое значение, не теоретический. Вспомогательный, не самостоятельный

14

4.Объектно-ориентированные – БД, основанные на объектной модели данных. Основным элементом объектной модели данных является «класс» и объект, который создается на основе этого класса. Класс представляет себя некий шаблон или можно сказать модель объекта, на основе которого создается сам объект. Класс также можно определить как тип данных определенный пользователем. Класс не является объектом, он лишь макет, на основе которого идет создание объекта. Объектно-ориентированный подход включает три основных столпа: полиморфизм, инкапсуляция и наследование.

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

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

6.«Ключ-значение» – Такой тип баз данных принято называть хранилище типа ключ-значение (key-value store). Фактически, никакого официального названия не существует, поэтому можно встретить такие названия как документо-ориентированные, атрибутно-ориентированные, шардированных упорядоченных массивов (sharded sorted arrays), распределенных хэш-таблиц и хранилищ типа ключ-значения. И хотя каждое из этих названий указывает на конкретные особенности системы, все они являются вариациями на тему, которую мы будем называть хранилище типа ключ-значение. Основной особенностью модели данных этого типа является то, что здесь фактически отсутствует какая либо упорядоченность в хранении. Т.е., есть некий четкий идентификатор (ключ) и набор свойств (значение), причем для каждой записи он может быть своим, т.е. иметь свой тип данных и даже разное количество свойств. Преимуществом такого подхода является некая простота построения – поскольку нет никаких типов и столбцов, есть только множество пар – «ключ-значение» и даже связи могут быть явно не определены. Такой подход позволяет создавать более гибкие базы данных с легко изменяемой структурой данных, что очень является очень важным аспектом. В остальном они похожи на РБД и даже обладают SQL подобным синтаксисом. Однако организованная подобным образом база данных обладает существенным недостатком – в ней чрезвычайно трудно производить поиск и сортировку данных, а также производить операции с атрибутами записей, поскольку они представляют единое значение. Кроме этого, практически невозможно контролировать целостность данных и наличие дубликатов. Применение данной модели данных или вида базы данных, по сути, ограничено, если только вам не все равно, что хранится в поле «значение». Однако, данные типы БД активно используются в веб-платформах хранения данных и облачных технологиях, когда явно не известно, какие данные будет хранить пользователь и какой объем ему нужен. Т.е., их можно сравнить с динамической памятью, при необходимости количество увеличивается.

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

15

ГЛАВА 2. АСПЕКТ СТРУКТУРЫ РМД.

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

2.1Основные понятия РБД.

Атеперь перейдем к более подробному рассмотрению РМД и РБД и рассмотрим 1-й аспект реляционной модели данных – аспект структуры. Как было сказано во вводной лекции аспект структуры отвечает на вопросы, как и что, описывается. Для того чтобы ответить на эти вопросы необходимо познакомиться с базовыми понятиями РМД и РБД.

Начнем с основополагающего понятия РБД – с понятия таблицы. Однако данное понятие в РБД отличается от привычного понимания таблицы.

1.Таблица (из лат. tabula — доска) (привычное понимание) – способ представления данных посредством создания специальной структуры, в которой отдельные элементы помещены в ячейки, которые находятся на пересечении строки и столбца. Пример - таблицы Excel.

2.Таблица (в рамках РБД) – способ хранения данных, посредством создания специальной структуры, данные в которой хранятся в ячейках, при этом на пересечении строки и столбца может быть только один элемент. Каждый столбец такой таблицы описывает одно свойство моделируемого объекта, их принято называть полями или атрибутами. А строка такой таблицы описывает один объект со всеми его свойствами, т.е. со всеми столбцами, ее принято называть запись.

Итак, мы определились, что таблицы в РБД используются именно для хранения данных, а

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

Какие типы данных существуют и что такое тип данных? Что такое тип вообще?

Тип — совокупность элементов, некоторого множества (или все это множество).

Тип данных – множество значений и правил, которые над ними можно производить.

В современных БД выделяют 5 типов данных:

1)Строковый тип (string, char, varchar и пр) используется для хранения символов.

2)Целочисленный тип (integer, byte, double и пр.) используется для хранения целых чисел

3)Вещественный (дробный) тип (real, decimal и пр.) используется для хранения чисел с дробной частью

4)Временной тип (date, time и пр.) используется для хранения даты и времени в различных форматах (дд.мм.гггг, дд месяца , 12:00:00 дд.мм.гг и др. форматы)

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

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

16

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

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

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

1.Отсутствие кортежей-дубликатов

2.Отсутствие упорядоченности кортежей

3.Отсутствие упорядоченности атрибутов

4.Атомарность (неделимость) значений атрибутов

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

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

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

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

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

Следует сказать пару слов о том, как выбирать первичный ключ: o Для начала нужно обратить внимание на его уникальность

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

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

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

17

2.2 Виды связей

Один – к – одному

Данный вид связи предполагает, что каждая запись в одной таблице связана не более чем с одной записью в другой таблице. Важно отметить тот факт, что не все записи могут участвовать в связи. Данный вид связи обычно применяется к тем свойствам объектов, которые могут отсутствовать и присутствовать с равной вероятностью, т.е. например наличие автомобиля у человека, сейчас около 40% людей имеют автомобили в Нижнем Новгороде. А, например, такое свойство как пол, нет смысла выделять в отдельную таблицу поскольку 100% вероятность у человека есть пол. Также объединять в одну таблицу свойства объекта если все записи участвуют в связи. Объединение таблиц называется композицией, а разбиение декомпозицией. Еще одним важным моментом является вопрос о равноправии таблиц, на данный вопрос можно ответить исходя из конкретной предметной области. Т.е. какая из таблиц главная, а какая ведомая.

Один – ко – многим

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

Многие – ко – многим

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

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

1.Каскадирование – изменения в одной таблице ведет к изменению в связанных таблицах.

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

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

2.3 Этапы проектирования баз данных. ER –модели. Проблематика проектирования

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

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

18

2.3.1 Концептуальный уровень

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

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

o естественный язык

o формализованный язык

Вбольшинстве случаев задание заказчиком дается либо в письменном либо в устном виде с использованием естественного языка. А уже дальше необходимо уточнять и проектировать предметную область на формализованном языке. К формальным языкам описания предметной области относятся UML (Unified Modeling Language, универсальный язык моделирования, 90-е

годы), SADT (Structured Analysis and Design Technique, структурный анализ и техника моделирования, 60-е годы) и еще ряд языков. Рассмотрение данных языков выходит за рамки данного курса.

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

2.3.2 Логический уровень

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

Сущность – абстракция (модель) реально существующего объекта или процесса.

Связь – отношения между сущностями (связь также может являться сущностью). Следует сказать, что типы связей между сущностями совпадают с типа связи в РБД.

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

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

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

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

19

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

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

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

Отделы

(Номер отдела, Название отдела, ...)

Служащие

(Табельный номер, Фамилия, ...) Зачисление [Отделы M, Служащие N]

(Номер отдела, Табельный номер, Дата зачисления).

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

Отделы

(Номер отдела, Название отдела, ...)

Служащие

(Табельный номер, Фамилия, ... , Номер отдела, Дата зачисления)[Отделы]

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

Рисунок 1. Обозначения сущностей в er-модели

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

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

2.3.3 Физический уровень

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

20